Legacy DAST Can’t Log In—And That Breaks Everything

Authentication Has Changed. Scanners Haven’t.

Modern apps don’t rely on cookies and login forms anymore.

They use:

• OAuth2 and OIDC flows
• JSON Web Tokens (JWTs)
• API keys and service-to-service tokens
• Mobile auth and 3rd-party identity providers

But many security scanners—especially legacy DAST tools—still assume a web form and session cookie.

And when they can’t authenticate, they can’t test.
That means you’re not scanning the parts of your app that matter most.

Here’s the harsh reality: 73% of critical vulnerabilities exist in authenticated parts of applications—the admin panels, user dashboards, and API endpoints that require valid tokens. But if your scanner can’t get past the login flow, you’re essentially running security theater on your marketing pages while your actual application remains untested.

This isn’t just a technical inconvenience. It’s a fundamental security gap that grows wider every day as applications become more API-centric and authentication becomes more sophisticated.

---

What We Hear from Teams

This isn’t theoretical—it’s operational.

“Our scanner can’t even get past login.”

One AppSec team told us they spent three weeks trying to get their legacy scanner to authenticate with their OAuth2 + PKCE flow. The scanner’s documentation mentioned “OAuth support,” but it only handled basic OAuth2 without PKCE extensions. Their entire SaaS platform was inaccessible to security testing.

“We have APIs with real-world token chains and none of them get tested.”

A fintech company shared that their payment APIs require service-to-service authentication with rotating client certificates, plus JWT tokens with specific scopes for each endpoint. Their scanner could handle basic API keys, but couldn’t navigate the multi-layered auth their compliance requirements demanded.

“We build for OAuth. But security tooling still assumes form-based auth.”

A development team at a healthcare startup explained it perfectly: “We don’t have login forms. We use Auth0 with social logins and MFA. But our scanner keeps looking for username/password fields that don’t exist.”

“Auth is a constant support ticket. We get it working with a recorder, then two days later it breaks again.”

This is the most common complaint. Teams spend days configuring authentication workflows, only to have them fail silently when:

• Token expiration logic changes
• Identity provider configs are updated
• New MFA requirements are added
• API scopes are modified
• Development environments refresh credentials

The “Recorder” Problem:

One team shared that their legacy scanner relied on a built-in “Recorder” to simulate login. It worked… briefly. Then broke. Again and again.

The recorder captured their initial login flow, but couldn’t adapt when:

• Their identity provider added CAPTCHA protection
• Token refresh logic was updated
• New API endpoints required different scopes
• Development credentials were rotated

Every time they updated a token flow or made an IDP config change, the scanner would silently fail. Entire sections of their app—everything behind login—were skipped without warning. The only solution? Another support ticket.

But here’s the real problem: They didn’t know it was broken. The scanner would complete successfully, report findings on public endpoints, and never mention that 80% of their application was never tested.

That’s not security testing. That’s expensive guesswork with a false sense of security.

---

 Why Auth Breaks Legacy Tools

Legacy DAST makes assumptions:

• That login is done with form fields and a POST request
• That it can capture a session cookie and replay it
• That auth is a one-time step at the start of a scan

But modern authentication:

• Uses multi-step flows (redirects, tokens, client secrets)
• Requires interactive tokens (PKCE, OIDC)
• Separates auth from the frontend entirely
  

And in APIs, it’s often:

• Scoped per endpoint
• Rotated dynamically
• Generated programmatically at runtime
  

If your scanner doesn’t speak your auth language, it can’t even open the door.

The Technical Reality:

Modern authentication is fundamentally different from the form-based login that legacy scanners were designed for:

OAuth2 + PKCE Flows: These require dynamic code generation, state management, and multi-step redirects. Legacy scanners expect a simple POST to /login—they can’t handle the cryptographic challenges and callback URLs that modern OAuth flows require.

JWT Token Management: JWTs contain encoded claims, expiration times, and scope limitations. They’re not just session identifiers—they’re structured data that determines what each request can access. Legacy scanners treat them like session cookies, missing the nuanced authorization they enable.

Service-to-Service Authentication: APIs often authenticate using client certificates, mutual TLS, or signed requests. There’s no “login page” at all—authentication happens at the protocol level. Legacy scanners looking for HTML forms can’t even begin this process.

Dynamic Token Scoping: Modern APIs often require different tokens for different endpoints, or tokens with specific scopes. A scanner might successfully authenticate for read operations but lack the proper scope for write operations—meaning it never tests the most dangerous parts of your API.

Identity Provider Integration: Applications increasingly rely on external identity providers (Auth0, Okta, Azure AD) with complex integration requirements. Legacy scanners can’t navigate these relationships or handle the redirects and callbacks they require.

The Silent Failure Problem:

Here’s what makes this especially dangerous: Legacy scanners often fail silently.

They’ll report “scan complete” without mentioning that authentication failed. They’ll test public endpoints and report vulnerabilities in your marketing pages while completely missing the authenticated application where real user data lives.

Security teams see a completed scan report and assume their application was tested. Development teams see no security findings and assume their authenticated endpoints are secure. Everyone’s wrong.

---

What Good Looks Like

Security testing should:

Handle Token-Based Workflows (JWTs, OAuth, API keys): Modern scanners need to understand token structure, manage refresh logic, and handle different token types for different endpoints. This isn’t just about capturing a token—it’s about understanding how that token grants access throughout your application.

Support Re-Authentication Logic During Scans: Long-running scans need to handle token expiration gracefully. When a JWT expires mid-scan, the tool should automatically refresh credentials and continue testing—not silently skip authenticated endpoints.

Work with Header-Based and Parameter-Based Credentials: APIs use authentication in headers (Bearer tokens), query parameters (API keys), and custom authentication schemes. Your scanner needs to support all of these, not just session cookies.

Integrate Easily into CI/CD, Not Rely on Interactive Browser Sessions: Developer workflows require automated testing. If your scanner needs someone to manually log in through a browser every time, it can’t run in CI/CD pipelines or automated security testing workflows.

Handle Complex Authentication Scenarios:

• Multi-tenant applications where different users see different endpoints
• Role-based access where admin users can access functionality that standard users cannot
• API keys with different permission levels
• Client certificate authentication for B2B integrations

Provide Authentication Debugging: When authentication fails, you need clear error messages and debugging information. “Authentication failed” isn’t helpful—”Token expired at step 3 of OAuth flow” is actionable.

Real-World Authentication Examples:

SaaS Multi-Tenant Application: Each tenant has isolated data and different feature sets based on subscription level. Your scanner needs to authenticate as different user types across different tenants to test authorization boundaries properly.

Financial Services API: Requires client certificates for initial authentication, followed by JWT tokens with specific scopes for different account types. Each API endpoint requires different permission levels—your scanner needs to understand these nuances.

Healthcare Platform: Uses SAML for provider authentication, OAuth2 for patient access, and API keys for third-party integrations. A single application with three different authentication methods—all of which need security testing.

🔐 Learn how StackHawk handles authentication

---

 Real Authentication = Real Coverage

The biggest risk isn’t that your scanner fails to log in. It’s that it silently skips everything behind login.

And for most applications today, that’s where the real security risks live:

Admin API Endpoints: User provisioning APIs, system configuration endpoints, financial data access services—the APIs that power admin functionality contain the highest-privilege operations in your application. These endpoints often bypass normal user restrictions and have direct database access. If your scanner can’t authenticate to test these APIs, you’re missing the attack paths that matter most to sophisticated adversaries.

Internal APIs: Service-to-service communication, data processing endpoints, integration points with third-party systems. These APIs often have the most permissive access because they’re “internal”—making them critical security testing targets.

User-Specific Data Flows: Personal data access, account management, privacy controls. Testing these flows requires authenticating as different user types to ensure proper data isolation and authorization controls.

Authorization Paths: Role-based access controls, permission escalation paths, administrative overrides. These can only be tested with authenticated access that exercises different permission levels.

Third-Party Integrations: API connections to payment processors, identity providers, data analytics platforms. These integration points often have complex authentication requirements and represent significant attack surface.

The Coverage Gap:

Consider a typical SaaS application:

• Public endpoints: Marketing pages, documentation, login forms (5% of functionality)
• Authenticated endpoints: User dashboards, admin panels, API integrations (95% of functionality)

If your scanner can’t authenticate, you’re testing 5% of your application and calling it security coverage.

Real-World Impact:

A customer told us their previous scanner had been running monthly scans for two years, consistently reporting “no critical vulnerabilities found.” When they switched to StackHawk and properly authenticated their scans, they immediately discovered:

• 12 broken object-level authorization (BOLA) vulnerabilities in user data endpoints
• 3 privilege escalation paths in admin functionality
• 8 business logic flaws in authenticated API workflows

These vulnerabilities had existed for years, completely invisible to their legacy scanner that couldn’t get past the login flow.

The Business Cost of Authentication Failures

Let’s talk about what this really costs organizations:

False Security Confidence: Teams believe their applications are secure because scans complete without critical findings. In reality, the most important parts of their applications were never tested. This false confidence delays investment in real security improvements and creates vulnerability to attacks.

Wasted Security Resources: Security teams spend weeks configuring authentication workflows that break with every application update. These resources could be spent on actual vulnerability remediation instead of fighting with tooling.

Delayed Development Cycles: When authentication breaks in CI/CD pipelines, it blocks deployments and forces manual intervention. Development teams start skipping security checks to maintain velocity—exactly the opposite of what you want in a shift-left security program.

Compliance Gaps: Many compliance frameworks require testing authenticated functionality. If your scanner can’t authenticate, you’re not meeting these requirements—regardless of what your scan reports say.

Incident Response Costs: The vulnerabilities that exist in authenticated parts of applications are often the most severe when exploited. The cost of breach response, customer notification, and reputation damage far exceeds the investment in proper security testing tools.

The Bottom Line

Authentication isn’t optional. It’s the gateway to your attack surface.

If your scanner can’t handle modern auth, it can’t test your app.

You don’t need workarounds or fake logins.
You need security testing that works with your application’s real identity model.

---

Want to see how StackHawk helps teams test APIs with real-world authentication? → Get a Demo

Read on for the rest of the Blog Series:

Why Legacy DAST Fails for Modern Applications and How to Fix It: https://www.stackhawk.com/blog/why-legacy-dast-fails-for-modern-applications-and-how-to-fix-it/

It’s Not That APIs Are Stateful—It’s That Context Matters: https://www.stackhawk.com/blog/api-security-needs-context-not-just-endpoints/

Legacy DAST is Dead! Long Live Modern DAST!: https://www.stackhawk.com/blog/long-live-dast-evolution-of-dynamic-api-security-testing/