Skip to main content
availability

Deployment: Invicti Platform on-demand, Invicti Platform on-premises

Consequences of scanning without trustlisting

If your scans are taking longer than expected, missing vulnerabilities, or failing to complete, network security controls may be interfering with Invicti's scanning process. This document explains what happens when scanner traffic isn't properly allowed and how to fix these issues.

Common signs your security controls are blocking scans​

Scan performance issues:

  • Scans taking significantly longer than expected
  • Scan engines reporting connectivity issues
  • Frequent scan timeouts or failures
  • Inconsistent results between repeated scans

Coverage problems:

  • Large portions of your application remaining untested
  • Missing vulnerability detections that should be found
  • Authentication sequences failing unexpectedly
  • Reduced crawling coverage

Unusual scan behavior:

  • HTTP 403, 406, or 429 error responses
  • CAPTCHA challenges appearing during scans
  • Scanner IP addresses being temporarily blocked
  • Session invalidation during testing

How security controls interfere with vulnerability scanning​

Vulnerability scanners like Invicti work by intentionally sending attack-like payloads to detect security weaknesses. This legitimate security testing can trigger protective systems that mistake scanner activity for real attacks.

Web Application Firewalls (WAF)​

What they do: WAFs analyze HTTP requests and block patterns that look like attacks.

How they interfere with scanning:

  • Block or sanitize security test payloads before they reach your application
  • Replace HTTP responses with generic error pages
  • Trigger CAPTCHA challenges that prevent automated crawling
  • Return false negatives by filtering out vulnerability probes

Business impact:

  • Critical vulnerabilities go undetected because test payloads never execute
  • Compliance requirements aren't met due to incomplete security coverage
  • False sense of security from scans that appear successful but miss real issues

Intrusion Prevention Systems (IPS)​

What they do: Monitor network traffic and automatically block suspicious activity.

How they interfere with scanning:

  • Temporarily block scanner IP addresses after detecting attack patterns
  • Reset connections mid-scan when payload thresholds are exceeded
  • Filter or throttle traffic patterns that resemble automated attacks

Business impact:

  • Interrupted scans that must be restarted multiple times
  • Incomplete vulnerability assessments that miss entire application sections
  • Increased testing costs due to failed scan attempts and manual intervention

DDoS Protection Services​

What they do: Detect and mitigate high-volume or abnormal traffic patterns.

How they interfere with scanning:

  • Apply rate limiting during intensive vulnerability testing phases
  • Present JavaScript or CAPTCHA challenges that scanners cannot solve
  • Block scanner traffic that resembles automated bot activity

Business impact:

  • Reduced test coverage when scanners can't access protected endpoints
  • Inconsistent scan results due to intermittent blocking
  • Delayed security assessments that impact release schedules

Rate Limiting and Traffic Controls​

What they do: Protect application stability by limiting request frequency.

How they interfere with scanning:

  • Return HTTP 429 responses during comprehensive security testing
  • Cause delays that extend scan duration beyond acceptable timeframes
  • Interrupt parallel testing needed for thorough vulnerability coverage

Business impact:

  • Extended testing windows that delay development cycles
  • Incomplete endpoint testing when rate limits prevent full coverage
  • Scan timeouts that require manual intervention and restart

Application-Level Security Controls​

What they do: Protect individual applications through various detection mechanisms.

Examples include:

  • Bot detection systems that identify non-human traffic
  • Request fingerprinting that blocks automated testing tools
  • Behavioral anomaly detection that flags unusual access patterns
  • Authentication lockout policies that prevent repeated login attempts

How they interfere with scanning:

  • Invalidate scanner sessions during authentication testing
  • Block login attempts needed for authenticated scanning
  • Filter requests based on user-agent or traffic fingerprints
  • Return dynamic responses that confuse vulnerability detection

Business impact:

  • Authentication vulnerabilities missed when scanners can't log in
  • Incomplete application testing in areas requiring user access
  • Inaccurate vulnerability verification due to filtered responses

How to ensure accurate and complete scans​

Essential trustlisting steps​

For optimal scan accuracy, configure your security infrastructure to allow scanner traffic:

  1. Allowlist Invicti scanner IP addresses

  2. Bypass WAF inspection for scanner traffic

    • Create rules that allow security testing payloads from scanner IPs
    • Disable content filtering for vulnerability assessment traffic
    • Ensure scanner requests reach your application unchanged

  3. Relax rate limiting during scheduled scans

    • Temporarily increase rate limits for scanner IP addresses
    • Allow higher concurrent request volumes during testing windows
    • Configure longer timeout periods for comprehensive testing

  4. Ensure authentication endpoints allow scanner access

    • Exempt scanner IPs from authentication lockout policies
    • Allow repeated login attempts needed for authenticated testing
    • Verify scanner sessions remain valid throughout scan duration

  5. Configure DDoS protection for legitimate testing

    • Mark scanner IP addresses as trusted traffic sources
    • Disable challenge responses for known scanner addresses
    • Allow automated traffic patterns during scheduled testing

Validation steps​

After implementing trustlisting, verify proper configuration:

  1. Test scan performance

    • Compare scan duration before and after trustlisting
    • Verify scans complete without connectivity errors
    • Check that crawling coverage meets expected levels

  2. Validate vulnerability detection

    • Run test scans against known vulnerable applications
    • Confirm security payloads execute without interference
    • Verify authentication testing functions properly

  3. Monitor scan consistency

    • Compare results across multiple scan runs
    • Check for reproducible vulnerability findings
    • Ensure consistent application coverage

The cost of inadequate trustlisting​

Without proper allowlisting, organizations face several risks:

Security risks:

  • Undetected critical vulnerabilities that could lead to breaches
  • Incomplete compliance assessments that fail regulatory requirements
  • False security confidence based on compromised scan results

Operational costs:

  • Increased testing time due to scan failures and restarts
  • Manual intervention required to troubleshoot scan issues
  • Delayed release cycles caused by unreliable security testing

Resource waste:

  • Wasted scanner resources on incomplete or failed scans
  • Increased support requests to resolve scanning problems
  • Repeated testing attempts that could be avoided with proper configuration

Getting help with trustlisting​

If you're experiencing scan accuracy issues:

  1. Review your current trustlisting configuration against our regional guides
  2. Check scan logs for blocked requests or connectivity errors
  3. Test with a simple target to isolate configuration issues
  4. Contact Invicti support if problems persist after implementing proper trustlisting

Proper trustlisting is essential for accurate vulnerability assessment. Taking time to configure your security infrastructure correctly ensures reliable, comprehensive security testing that protects your organization effectively.

Need help?​

Invicti Support team is ready to provide you with technical help. Go to Help Center

Last updated on
Was this page useful?