Home / Knowledge hub / Authenticated scan
Knowledge hub
Authenticated scan
A scan that signs in first so it can see behind the login.
What it means
An authenticated scan is a vulnerability scan that signs in with real credentials before it starts, so that it can reach the pages and functions behind the login. An unauthenticated scan stops at the front door and sees only what the public sees.
The credentials are usually for a test account that you create for the purpose. The scanner uses them to hold a session, walk the signed-in part of the application, and test the forms and endpoints it finds there, as a signed-in customer would use them.
Why it matters
Most of the value in a business application sits behind the login: customer records, payments, settings, admin tools. An anonymous scan covers little of that, so it can report a clean result for an application that has plenty of problems inside.
Signed-in scanning also checks more of the system itself. On a host, a signed-in scan can read installed software and settings and find missing patches that an outside view cannot confirm. It tends to produce fewer false alarms, because it can see what is installed instead of guessing.
How it shows up
Setting it up well takes care. Give the scanner a dedicated account with the least access that still reaches what you want covered, and use a test environment where possible. Tell it how to detect a logged-out session so it can sign back in, and tell it which links to avoid, such as delete and logout.
The mistakes repeat. Sessions expire halfway and the scan quietly tests the login page for hours. An admin account is used on production and the scanner deletes real data. Or one low-access account is tested, so nothing beyond it is covered. See authenticated testing and cross-account access.
Questions people ask
Authenticated scan, answered
What is the difference between an authenticated and unauthenticated scan?
An unauthenticated scan sees only what an anonymous visitor sees. An authenticated scan signs in first and sees the signed-in application, so it covers far more of what a real user can reach.
Is an authenticated scan safe to run on production?
It can be, with care. Use a least-privilege test account, exclude destructive actions such as delete, and run in a quiet window. Where you can, test a staging copy first.
Which account should the scanner use?
A dedicated test account with no real customer data. Use more than one level of access if you want coverage of different parts, and never reuse an account that real staff depend on.
Why does the scan keep getting logged out?
Sessions can expire, or the scanner may trigger the logout link. Configure session detection and exclude the logout path, so the scanner can sign in again and keep going for the whole run.
Does an authenticated scan find access control flaws?
Only some of them. It can reach protected pages, but judging whether one account should see another's data needs knowledge of intent. That usually calls for manual testing or a tool that understands your application's rules.
Sources
Where this comes from
Related
Terms that sit next to this one
Authenticated testing
Testing the parts of an application that only signed-in accounts can reach.
Vulnerability scanning
Automated checks that look for known weaknesses without proving they can be used.
Grey-box testing
Testing an app with some inside knowledge, such as accounts and docs, but not the code.
Cross-account access
One signed-in account reaching another account's data or functions.
DAST
Tools that attack a running application from the outside.
What sits behind your login?
Grey-box testing starts with accounts you give us, then checks what each signed-in account can reach that it should not. Findings come with the request that proves them. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.