What is a false positive?
A false positive is a finding that Shieldome reports as a potential vulnerability, but which is not actually exploitable in your environment. For example, Shieldome might flag a redirect as a potential open redirect, but your application's allow-list makes it safe in practice.
False positives are common in automated scanners because they operate without knowledge of your business logic, your allow-lists, your WAF, or your infrastructure setup. Shieldome is designed to be conservative — it is better to flag something that isn't a risk than to miss something that is.
How to tell a real finding from a false positive
Before marking a finding as a false positive, do the following:
- Read the evidence section of the finding card. Shieldome shows what it observed — the URL tested, the response code, headers, or content it matched on.
- Reproduce it manually. Try the same request in a browser or with
curl. If you can't reproduce any unexpected behaviour, it is likely a false positive. - Check your WAF / reverse proxy logs. Did the probe request actually reach your application? If a WAF blocked it and Shieldome detected the block as a 5xx, the underlying application might be fine.
- Check with your developer. Some findings (e.g. "login page without CAPTCHA") are design choices, not vulnerabilities — your team may have intentional reasons for the current setup.
Common legitimate false positives
| Finding | Why it may be a false positive |
|---|---|
| Open redirect indicator | Redirect only follows an allow-listed set of URLs controlled by your app |
| Directory listing detected | The listing is intentional (e.g. a public file server) or protected by auth |
| Server version disclosure | Your WAF or CDN is stripping headers; Shieldome saw the raw backend headers |
| Missing security header | Header is set by your CDN and not reflected in a direct HTTP response |
| SQL error indicator | The word "syntax error" appears in a legitimate error message, not from injection |
| Sensitive path accessible | Path returns 200 but is protected by application-level auth (not HTTP 401) |
| Subresource Integrity missing | Your CDN adds integrity attributes after the response leaves your origin |
Suppressing a false positive
To suppress a finding in the current scan result:
- Open the scan result and find the finding you want to suppress
- Click the ⋮ button (three dots) on the right side of the finding card
- Click ⊘ False Positive
- Optionally enter a short note explaining why — this note appears as a tooltip on the badge
- Click Confirm
The finding will be tagged with an ⊘ FP badge and the suppression is remembered globally for that target URL + finding combination. Future scans of the same URL will automatically mark matching findings as false positives.
Reviewing suppressed findings
Suppressed findings are not deleted — they remain visible in the scan with their ⊘ FP badge so you have a complete audit trail. They are excluded from severity counts and PDF reports but are always visible in the full findings list. To remove a false positive suppression:
- Click the ⋮ menu on the suppressed finding
- Click Clear Status
What to do if you believe the scanner is wrong
If you think Shieldome is consistently generating false positives for a specific check, contact support at [email protected] with:
- The scan ID
- The finding name and severity
- What you observed when you tried to reproduce it manually
- Any relevant headers, response bodies, or WAF/proxy configuration
We use this information to tune detection heuristics and reduce false positives in future scanner versions.
Reducing false positives with scan configuration
Some false positives arise from scanning the wrong environment. Tips:
- Scan production, not staging — staging environments often have weaker security headers, allowing-headers removed, and self-signed certs. Results from staging may look worse than production.
- Use the IP Override field — if your domain points to a CDN that strips headers, override the IP to point directly at your origin server to get the accurate server-level headers.
- Scan after deployment — scanning a URL before your latest deployment is live will produce results based on old code.
Bulk false-positive workflow
When a scan returns many false positives — common for security headers on specific paths or overly sensitive checks — use the bulk workflow to process them efficiently:
- Open the Triage tab from the navigation bar.
- Use the OWASP category filter to narrow findings to the category with false positives.
- Tick the checkbox on each false positive (or use Select all in this view).
- Click Mark selected as False Positive in the bulk action bar.
- Optionally add a note (e.g., "Header present on CDN layer, not visible from origin") — this note is saved on all selected findings.
Once marked, false positives are excluded from the risk score and moved out of the active triage queue. They remain in the audit log. If a false positive re-appears in a future scan, it is automatically re-opened for review.
Risk acceptance vs. false positive
Use False Positive when the finding is incorrect — the vulnerability doesn't actually exist. Use Risk Acceptance when the finding is real but your team has made a conscious decision not to fix it (e.g., a header not applicable to your stack). Both are tracked separately in the audit trail.