Managing False Positives

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. Automated scanners operate without knowledge of your business logic, WAF rules, CDN configuration, or allow-lists - so they sometimes flag things that are safe in your specific context.

Shieldome is intentionally conservative: it is better to flag something that isn't a risk than to miss something that is. This means a small number of false positives is expected and normal.

When false positives commonly appear

The most frequent sources of false positives:

• Security headers stripped by a CDN. Your origin server sets Content-Security-Policy correctly, but your CDN (Cloudflare, Fastly, AWS CloudFront) removes or overrides it before the response reaches Shieldome. The scanner sees a missing header and flags it.
• CORS configured intentionally. Your API deliberately returns permissive CORS headers for a public API. Shieldome flags permissive CORS as a misconfiguration, but in your context it is a deliberate design choice.
• WAF blocking a probe request. Shieldome sends a benign probe and receives a 5xx from your WAF. The scanner interprets this as a potential server error, but the application itself is healthy.
• Sensitive path accessible but protected by app-layer auth. A path returns HTTP 200, triggering a "sensitive path accessible" finding, but the response body is behind application-level authentication that the scanner cannot see.
• Server version disclosure from a CDN edge node. The Server header shows the CDN's version, not your application stack. Shieldome flags version disclosure, but you have no control over the CDN header.
• Subresource Integrity (SRI) added by CDN. Your CDN injects integrity attributes after responses leave your origin, but Shieldome scans the origin directly and sees them missing.

How to tell a real finding from a false positive

Before marking a finding as a false positive, investigate it:

1. Read the evidence section of the finding card. Shieldome shows what it observed - the URL tested, the response code, headers, and the specific content it matched on.
2. Reproduce it manually with curl or in a browser. If you can't reproduce any unexpected behaviour, it is likely a false positive.
3. Check your WAF and reverse proxy logs. Did the probe actually reach your application, or was it intercepted?
4. Check with the developer or infrastructure team. Some findings (e.g. "no CAPTCHA on login page") may reflect deliberate design choices that your team is aware of and has accepted.

Common legitimate false positives

Marking a finding as False Positive

To mark a finding as a false positive:

1. Open the scan result and locate the finding.
2. Click the ⋮ (three-dot) menu on the right side of the finding card.
3. Click Mark as False Positive.
4. Enter an optional note explaining why (e.g. "Header added by Cloudflare - not present at origin"). This note appears as a tooltip on the suppression badge.
5. Click Confirm.

The finding is tagged with an ⊘ FP badge. The suppression is applied globally for that target URL + finding type combination - future scans of the same URL will automatically mark matching findings as false positives without requiring another manual review.

Accepting risk

Use Accept Risk when the finding is real - the vulnerability genuinely exists - but your team has made a deliberate, documented decision not to fix it right now. Examples: a deprecated security header that does not apply to your stack, or a known issue scheduled for remediation next quarter.

To accept risk on a finding:

1. Click the ⋮ menu on the finding card.
2. Click Accept Risk.
3. Enter a written justification (required - this is mandatory for compliance audit purposes).
4. Set an expiry date - the risk acceptance is automatically revoked on this date and the finding returns to Open status to prompt re-review.
5. Click Confirm.

Accepted-risk findings are tagged with a ✓ Accepted badge and excluded from the active risk score. When the expiry date passes, the finding automatically reverts to Open and the scan owner receives a reminder email.

False Positive vs. Accept Risk - when to use each

Audit trail

Every false-positive suppression and risk acceptance is permanently recorded in the finding's history. The audit trail shows:

• Who marked the finding and when (timestamp and user name)
• The status change (Open → False Positive, Open → Accepted, Accepted → Open on expiry)
• The note or justification text
• The expiry date (for risk acceptances)

Suppressed findings are never deleted - they remain visible in the full findings list with their badge, excluded from severity counts and PDF reports by default. To include suppressed findings in a PDF report, enable "Include suppressed findings" in the report generation dialog.

Suppression and future scans

Once you mark a finding as a false positive for a given target URL, that suppression is remembered. When the same target is scanned again - manually or via a scheduled scan - any matching finding is automatically marked as a false positive and excluded from the active risk score. You do not need to re-review it each time.

If the underlying condition changes (for example, your CDN configuration changes and the header is now genuinely missing), you can reopen the finding: click the ⋮ menu on the suppressed finding and select Reopen.

API reference

Update a finding's status

{
  "finding_id": "f1a2b3c4-...",
  "status":     "false_positive",   // "false_positive" | "accepted" | "open"
  "note":       "Header set by CDN - not visible at origin"
}

{
  "finding_id":  "f1a2b3c4-...",
  "status":      "accepted",
  "note":        "Scheduled for remediation in Q4 2026 sprint",
  "expires_at":  "2026-12-31"        // ISO 8601 date; required for "accepted" status
}

To reopen a suppressed finding, send the same request with "status": "open".

Bulk actions

When a scan returns many false positives - common for security header checks or SRI findings on a CDN-fronted site - use the bulk workflow:

1. Open the Triage tab from the scan result navigation.
2. Use the OWASP category filter to narrow findings to the category containing the false positives.
3. Tick the checkbox on each false positive, or use Select all in this view.
4. Click Mark selected as False Positive in the bulk action bar at the bottom of the screen.
5. Optionally add a shared note - it is saved on all selected findings at once.

Once marked, the 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 in a different context (e.g. you changed CDN providers), it is automatically re-opened for review.

Reducing false positives with scan configuration

Some false positives arise from scanning through the wrong layer of your stack. Tips to get cleaner results:

• Use the IP Override field - if your domain points to a CDN that strips or adds headers, override the IP to point directly at your origin server to get accurate server-level results.
• Scan production, not staging - staging environments often have weaker security configuration. Results from staging may appear worse than production.
• Scan after deployment - scanning before your latest deployment is live produces results based on old code.
• Use an authenticated scan profile - for paths that return 200 but are protected by application auth, enable Playwright and inject a session cookie so the scanner evaluates the authenticated state.

Reporting scanner inaccuracies

If Shieldome consistently generates false positives for a specific check across multiple targets, contact support at [email protected] with the scan ID, the finding name, and what you observed when reproducing it manually. We use this information to tune detection heuristics in future scanner versions.