Skip to content

Authenticated vs unauthenticated scans

When to go to the trouble of authenticated scans and when the view from outside is enough.

Updated · authenticated · webapp

Unauthenticated scans see your app the way an attacker on the internet does. Authenticated scans see your app the way a logged-in user does. Both are useful; neither is a replacement for the other.

Authenticated gives you more…

  • Authorization bugs (horizontal/vertical privilege escalation).
  • Post-login XSS, IDOR, SSRF.
  • State-dependent vulnerabilities that only appear after a form submission.

…at a cost

Authenticated scans require credentials, a test user, and often session management configuration (handling CSRF tokens, re-auth, rate limits). Budget at least half a day for the first setup of each app. Rotate the test account's password regularly and never use a real employee's credentials.

Safety checklist before enabling

  • Use a dedicated test account, never a real user.
  • Disable destructive endpoints for that account (or scope them to test data).
  • Warn your data team — scans generate spikes in logs and analytics.
  • Run the first authenticated scan out-of-hours so rate limits don't affect real users.