You Don't Need Authentication on Every API

The conventional wisdom says every API endpoint must require authentication. No exceptions. It's the first thing we teach junior engineers, the first control we audit, and the baseline assumption in every security framework.

Here's the problem with that absolutism: it makes teams treat authentication as a checkbox instead of understanding what they're actually protecting and why.

Why This View Misses the Point

The Vatican's official prayer app leaked personal information of over 700,000 users through a porous API endpoint. Security researchers could pull names, email addresses, and country details without any credentials. The immediate reaction? "They forgot to add authentication!"

But authentication wasn't the root failure here. The failure was exposing personally identifiable information through an endpoint in the first place.

Think about what authentication actually does: it tells you who is making the request. It doesn't tell you whether that person should see the data they're requesting. You can have perfectly implemented OAuth 2.0 with JWT tokens and still leak user data to authenticated attackers. The Vatican app's real problem wasn't missing authentication, it was that the API returned sensitive user data when it shouldn't have returned any user-identifying information at all.

This matters because when you treat "add authentication" as the solution, you stop asking the harder questions:

• Why does this endpoint return PII?
• What's the minimum data this endpoint needs to expose?
• Who should be authorized to see this specific resource?

The Evidence from Your Own Stack

Look at your production APIs right now. I'll bet you have public endpoints that don't require authentication. Your health check endpoint (/health or /status) probably returns service status without credentials. Your OpenAPI documentation might be publicly accessible. If you're running a SaaS product, you likely have public endpoints for pricing, feature lists, or blog content.

These are fine. They're designed to be public. The data they expose is intentionally non-sensitive.

Now look at your authenticated endpoints. How many of them implement proper authorization checks? OWASP API Security Top 10 lists Broken Object Level Authorization as the #1 API security risk, not missing authentication. That's because most teams authenticate the user but fail to verify whether that authenticated user should access the specific resource they're requesting.

Consider a common pattern: You authenticate a user, get their user_id from the JWT, then let them request /api/users/{any_user_id}/profile. If you're not checking that the authenticated user_id matches the requested user_id, authentication is security theater. Any logged-in user can enumerate all other users.

PCI DSS v4.0.1 Requirement 6.4.3 addresses this directly: applications must prevent common attacks including "broken access control". Notice it doesn't say "missing authentication", it says broken access control. Authentication is step one. Authorization is the actual security control.

What to Do Instead

Start by classifying your API endpoints based on the sensitivity of data they expose, not whether they're "public" or "private":

Public by design: Health checks, documentation, marketing content. No authentication needed. No sensitive data exposed.

Authenticated but not user-specific: Feature flags, configuration settings, public reference data. Require authentication to prevent abuse and rate-limiting bypass, but authorization checks are minimal because the data isn't tied to specific users.

User-specific resources: This is where you need both authentication AND authorization. For every request to /api/users/{id} or /api/orders/{id}, verify:

1. The request includes valid credentials (authentication)
2. The authenticated identity has permission to access this specific resource (authorization)
3. The response filters data based on what this identity should see (data-level access control)

For the Vatican app scenario, the prayer intentions endpoint should have either:

• Returned only public, anonymized prayer counts (no authentication needed, no PII exposed)
• Required authentication and returned only the authenticated user's own data (authorization check on user_id)
• Not exposed individual user data through an API at all (architectural decision)

Your implementation checklist for any new endpoint:

1. What's the minimum data this endpoint needs to return? (Start here, not with authentication)
2. Does this data include anything user-specific or sensitive?
3. If yes to #2: Implement both authentication (who are you?) and authorization (can you access this specific resource?)
4. If no to #2: Consider whether authentication adds security value or just friction

OWASP ASVS v4.0.3 Section 4.1 breaks this down into testable requirements. V4.1.1 requires access control enforcement at a trusted layer. V4.1.2 requires that all user and data attributes used by access controls cannot be manipulated by end users. These requirements assume you've already authenticated the user, they're focused on what happens next.

When Conventional Wisdom IS Right

Authentication everywhere makes sense in specific contexts:

Internal APIs: If your API only serves your own applications, requiring authentication on every endpoint reduces attack surface. The friction cost is zero because your apps already have credentials.

APIs handling any regulated data: HIPAA, GDPR, PCI DSS environments benefit from defense in depth. Authentication on every endpoint means one less way to accidentally expose protected data.

High-security environments: Financial services, government systems, critical infrastructure. The cost of a breach outweighs the development overhead of universal authentication.

When you're unsure: If you can't confidently classify an endpoint's data sensitivity, require authentication. You can always relax it later; adding it after launch is harder.

The Vatican app needed authentication because it was exposing PII. But the lesson isn't "always authenticate", it's "never expose PII through an API unless you've implemented proper access controls." Authentication was one missing piece. Authorization, data minimization, and API design were the others.

Stop treating authentication as the goal. It's a tool for implementing access control. The goal is ensuring users only see data they're supposed to see, whether that's through authentication, authorization, data filtering, or not exposing the data through an API in the first place.

OAuth 2.0