Authenticated vs Unauthenticated Penetration Tests
An unauthenticated penetration test attacks your application from the outside with no login, so it only sees what a stranger sees. An authenticated penetration test is given working credentials, so it also tests everything behind the login: access controls between accounts, privilege escalation, and whether one customer can reach another customer’s records. If your application holds customer data behind a login, an authenticated test is the one that covers it.
That is the short answer. The longer answer matters because the two tests cost about the same to commission and produce very different reports, and Australian businesses regularly buy the wrong one.
What is the difference between an authenticated and an unauthenticated penetration test?
The difference between an authenticated and an unauthenticated penetration test is whether the tester is given working login credentials before testing starts.
In an unauthenticated test, the tester is treated as an anonymous attacker on the internet. They can reach your login page, your public pages, your APIs that do not require a session, and your server configuration. They cannot reach anything that requires an account, because they do not have one.
In an authenticated test, you create accounts for the tester, usually one for each user role in the application. The tester logs in and works through the application as a real user would, then tries to break the boundaries between roles and between customers. An authenticated test includes everything an unauthenticated test covers, and then continues past the login.
The same distinction exists in vulnerability scanning, where it is usually called a credentialed or non-credentialed scan. Penetration testing and scanning are not the same activity, and the difference is covered in penetration testing versus vulnerability scanning.
What does an unauthenticated web application test actually find?
An unauthenticated web application penetration test finds weaknesses that are reachable without an account. That is a real and useful set of findings, and for some applications it is the correct scope.
Typical findings from an unauthenticated web application penetration test include:
- Authentication weaknesses on the login, registration and password reset flows, including username enumeration and weak rate limiting
- Injection flaws in any input accepted before login, such as a search box or a contact form
- Exposed files, backups, administrative interfaces and development endpoints left reachable on the public internet
- Transport and configuration problems, including weak TLS settings and missing security headers
- Information disclosure in error messages, source maps and public API responses
What an unauthenticated web application penetration test cannot find is anything that requires a session. If ninety per cent of your application sits behind a login, an unauthenticated test has examined the remaining ten per cent.
What does an authenticated test find that an unauthenticated test cannot?
An authenticated penetration test finds the flaws that only exist once a user is logged in, and these are consistently the findings that matter most to a business holding customer data.
Findings that require authenticated access include:
- Broken access control between accounts. Customer A changes a record identifier in a request and reads Customer B’s invoice, file or personal information.
- Privilege escalation. A standard user reaches an administrative function by calling the API directly, because the control was only enforced in the user interface.
- Insecure direct object references. Sequential or guessable identifiers expose records the logged-in user was never meant to see.
- Business logic flaws. A paid feature is reachable on a free plan, a workflow step is skipped, or a discount is applied twice.
- Session handling problems. Sessions that survive a password change, tokens that do not expire, or a logout that does not invalidate anything server side.
Broken access control is the kind of flaw that leads to a notifiable data breach, because it exposes other people’s personal information rather than crashing a server. An unauthenticated test will not find it, because finding it requires being logged in as two different users and comparing what each can reach.
The OWASP Web Security Testing Guide sets out the authorisation and business logic test cases that depend on authenticated access, and it is a reasonable reference point when you are reviewing a proposed scope.
Which web application penetration test does your application need?
Choose an authenticated penetration test when your application has a login and holds information that belongs to someone other than you. Choose an unauthenticated test when there is no authenticated surface worth testing, or when the authenticated side has already been tested recently.
| If your application | Choose | Because |
|---|---|---|
| Has no login at all | Unauthenticated | There is no authenticated surface to reach |
| Has a login and holds customer data | Authenticated and unauthenticated | Access control flaws only appear once logged in |
| Has several user roles | Authenticated, one account per role | Escalation is tested between roles, not just within one |
| Is a public marketing site | Unauthenticated | The content is already public |
| Is a customer or client portal | Authenticated and unauthenticated | Personal information sits behind the login |
| Is pre-launch with test data | Authenticated and unauthenticated | Logic flaws are cheaper to fix before real data arrives |
A practical rule: if a breach of the application would require you to assess the incident under the Notifiable Data Breach scheme, the test needs credentials. Scoping is worth getting right the first time, and how to scope a penetration test walks through the decisions in more detail.
What do you need to provide for an authenticated penetration test?
An authenticated penetration test needs accounts, and arranging them is the step most often left until the week testing starts.
- One account per role. If the application has standard users, managers and administrators, the tester needs one of each. Testing escalation requires at least two accounts at different privilege levels.
- Two accounts at the same level. This is how a tester proves whether one customer can reach another customer’s data. A single account cannot demonstrate that boundary.
- A suitable environment. A staging environment that mirrors production is ideal. If testing must happen in production, agree in writing what the tester may and may not do with live records.
- Realistic data. An empty account hides flaws. Seed the test accounts with representative records so the tester can see how the application behaves with content in it.
- Accounts that survive the test window. Accounts that lock out, expire or get cleared by a nightly reset will stall the engagement.
Disable or delete the test accounts once the engagement finishes. The broader preparation checklist is set out in how to prepare for a penetration test.
Does an authenticated penetration test cost more?
An authenticated penetration test usually costs more than an unauthenticated test of the same application, because the tested surface is larger and the tester spends more days on it.
The driver is the number of roles and the size of the authenticated application, not the word authenticated itself. A small portal with two roles may be only marginally more than an unauthenticated test. A multi-tenant platform with six roles, an admin console and an API is a substantially bigger engagement.
What changes the economics is what you get back. An unauthenticated report on a data-heavy application tends to list configuration issues. An authenticated report on the same application tends to list the access control flaws that would actually expose customer records. Current Australian pricing ranges are set out in our penetration testing cost guide, and you can see current scope and pricing on the penetration testing service page.
Does ISO 27001 or SOC 2 require an authenticated test?
Neither ISO 27001 nor SOC 2 names authenticated penetration testing as a mandatory control. Both expect you to test the security of applications that process information in scope, and both leave the method to you. Auditors look at whether the test covered the risk.
In practice, an auditor who sees an unauthenticated-only report for a customer portal will ask how access control between customers was verified. If the answer is that it was not, that becomes a conversation about the adequacy of your testing rather than a tick. The expectations are covered further in whether penetration testing is required for SOC 2.
Common questions
What is the difference between authenticated and unauthenticated scans?
An unauthenticated scan probes a system from the outside with no credentials and reports what is visible to an anonymous attacker. An authenticated scan logs in, usually with an account or an agent, and inspects installed software, patch levels and configuration from the inside. Authenticated scans produce far fewer false positives because the scanner can confirm versions rather than guess them from banners.
Are security testing and penetration testing the same thing?
No. Security testing is the broad category and includes automated scanning, code review, configuration review and penetration testing. A penetration test is a manual, goal-driven exercise in which a tester actively attempts to exploit weaknesses and chain them together. Automated security testing finds known issues; a penetration test finds the ones that require human reasoning, such as business logic flaws.
Does an API need an authenticated test?
Almost always, yes. Most APIs expose very little without a token, so an unauthenticated API test covers authentication handling and little else. An authenticated API test checks whether tokens are scoped correctly, whether one tenant can request another tenant’s objects, and whether rate limits and authorisation checks apply on every endpoint rather than only the documented ones. API penetration testing covers the detail.
What is penetration testing suitable for?
Penetration testing suits any system where a real attacker would cause material harm: web applications holding personal information, external network perimeters, cloud environments, internal networks and mobile applications. It is less suitable as a first step for an organisation with no patching, no multi-factor authentication and no asset inventory, because the report will list problems already known. Fix the basics first, then test.
Can you run an unauthenticated test first and add credentials later?
Yes, and it is a reasonable approach for a first engagement on a public-facing application. Run the unauthenticated test, remediate what it finds, then commission an authenticated test on the same application. The trade-off is that two engagements cost more than one combined engagement, and the authenticated findings, which are usually the more serious ones, arrive later.
Getting the scope right
If your application has a login and real customer data sits behind it, an unauthenticated test on its own leaves the part that matters untested. Ask any prospective tester which of the two they are quoting for, how many roles are included, and whether access control between customers is in scope. A provider who cannot answer those three questions clearly is quoting on something other than your risk.
Siege Cyber is CREST-accredited and runs both authenticated and unauthenticated web application testing for Australian businesses. See the penetration testing service for scope and inclusions, or get in touch to talk through which test fits your application.