We run continuous security assessments at breka.ai. Fintech, healthcare platforms, SaaS tools, AI companies. Every engagement is different, but one class of finding shows up more than any other. More than weak email authentication. More than exposed secrets. More than misconfigured cloud storage.

It is an endpoint that never asks who you are.

In our latest batch of assessments, 46 out of 101 applications we attacked, 45 percent, had at least one endpoint that changes state or returns data with no authentication at all. Not a bypass. Not a token trick. The server simply never checks.

What missing authorization is

Every API endpoint has two questions to answer before it does any work.

Who is calling? That is authentication. Is this caller allowed to do this? That is authorization. When both questions go unasked, the industry name for it is CWE-862, Missing Authorization. OWASP puts Broken Access Control at the top of its Top 10 for a reason.

Missing authorization means an endpoint performs an action or returns data without verifying the caller's identity or permissions. It is the most common finding in our assessments: no stolen credentials, no exploit code, just a route that does its work for anyone who asks.

Here is the part most teams miss: these endpoints rarely look dangerous in isolation. Reserve a slot. Mark a booking as a no-show. Trigger a phone call. Query a log. Each one feels like a small internal operation, but attackers do not see small operations. They see primitives, and primitives chain into outcomes.

We keep finding source comments like // TODO: add auth here sitting directly above endpoints that are live in production. Everyone meant to come back to it. Nobody did.

What an attacker does with it

There is no exploit here. No malware, no stolen credentials, no clever encoding. One HTTP request, the same request the real frontend sends, sent by anyone on the internet.

curl -X POST https://api.example.com/api/v1/appointments/hold \
  -H "Content-Type: application/json" \
  -d '{"time": "2026-09-15T10:00:00Z"}'

Real findings from recent engagements, anonymized:

A scheduling tool let anyone block out arbitrary time on any user's calendar. The time silently vanished from that user's availability. A calendar-wide denial of service, one request at a time, against every customer at once.
A healthcare communications platform exposed an endpoint that accepts a phone number and starts a real outbound call. No token. The telephony provider does the dialing, and the target company pays the bill and takes the blame.
A payments platform let a stranger create an organization and its first administrator account. No email verification. A full account factory, open to the internet.
An insurance quoting API returned customer records and password hashes to anyone who asked for them by number.
An event platform returned hundreds of attendee records, names, emails, and meeting agendas, to an anonymous request.

None of these required an account. Most of them did not even require knowing a secret URL. The routes were guessable, documented, or shipped in the public JavaScript bundle.

Worth saying: in each of these engagements, most of the estate held up under direct testing. The login flows, the tenant isolation, the admin gating did their jobs. The finding is usually the one door nobody checked, not a building without locks.

Why this is a real problem

The consequences depend on what the company does, and they scale with trust.

For a healthcare vendor, an unauthenticated call endpoint is a way to phone patients with perfect context and a trusted caller ID. For a payments company, an open onboarding endpoint is fabricated corporate identity at a licensed money transmitter. For a scheduling tool, availability is the product, so deleting availability is deleting revenue.

There is a second-order problem too. Missing authentication is rarely the whole story in our reports. It is step one. A public endpoint gives the attacker a foothold. The foothold reveals an internal ID. The ID hands over a role. The role reaches the data. When we show a customer a confirmed compromise path, the first link is very often an endpoint that never asked who was calling.

Why companies ship unauthenticated endpoints

The reason is not incompetence. It is framing.

The endpoint felt internal. Modern frameworks generate dozens of RPC-style routes, and each one looks like a function call, not a public door. The frontend hides the button, so the developer assumes the route is hidden too. It is not. Anyone can read the bundle and replay the request.

Frameworks also default to open. Authentication is usually opt-in per route, which means every new route is a fresh chance to forget. And fixes drift. We regularly find a mutation gated in production but wide open in QA, in staging, and in the open-source main branch that every self-hosted customer runs.

Finally, the surface keeps growing. Teams ship new endpoints every week. A point-in-time review describes the release that was tested. The next release is a new set of dice.

How to fix missing authorization

The fix is architectural, not heroic. Four steps.

Step one. Make the default deny. Do not protect routes one at a time. Put authentication in middleware that runs on everything, and make public routes opt out explicitly.

// default-deny: every route requires a session unless marked public
const publicRoutes = new Set(["/health", "/docs"]);

app.use((req, res, next) => {
  if (publicRoutes.has(req.path)) return next();
  if (!req.session) return res.status(401).end();
  next();
});

If a route has no reason to be public, it should not be reachable. New endpoints are then safe by default, and the dangerous ones are the ones someone had to mark public on purpose.

Step two. Authenticate the actor, then authorize the action. A valid session is not permission. Before touching an object, check that this caller owns it or holds a role that may touch it. If your endpoint takes an ID from the request and trusts it, you have the cousin of this finding, broken object-level authorization, and we report that one constantly too.

Step three. Test like an attacker. For every endpoint, replay the request with no credentials and expect a 401. Replay it with your lowest-privilege account and expect a 403 unless that role genuinely needs it. Automate both checks in CI. The test suite should fail when an endpoint forgets to ask who is calling, the same way it fails when a function returns the wrong value.

Step four. Re-test after every release. Endpoint inventories go stale within weeks. The check that passed in March says nothing about the route that shipped in May. This is the reason continuous testing exists. The attack has to return when the software changes, because the software always changes.

The point

We keep reporting this finding because it is cheap to find and expensive to ignore. One missing check stands between the internet and your customers' data, their calendars, their phone lines, their money.

If you want to know where you stand, it takes a few minutes. Pick the five most sensitive endpoints in your API. Call each one from a clean session with no token, no cookie, no key. If any of them returns data, or worse, answers 200 to a write, that is the finding.

And if you would rather have someone who does this for a living ask the question, that is exactly what we do.

Frequently asked questions

What is missing authorization (CWE-862)?

Missing authorization is a flaw where an application performs an action or returns data without checking the caller's identity or permissions. MITRE tracks it as CWE-862. OWASP ranks its parent category, Broken Access Control, as the number one web application risk.

Is missing authorization the same as broken access control?

Broken access control is the OWASP category. Missing authorization, missing authentication, and broken object-level authorization (BOLA, or IDOR) are specific flaws inside it. In practice, they share one root cause: the server trusts the request without checking who sent it or what they may touch.

What is the difference between authentication and authorization?

Authentication answers who is calling. Authorization answers what that caller is allowed to do. An endpoint can have a valid login check and still be vulnerable if it never verifies that this user owns the record they are asking for.

How do I find unauthenticated endpoints in my API?

Replay each endpoint's request without credentials and expect a 401 or 403. Then replay it with your lowest-privilege account and expect a 403 unless that role genuinely needs access. Automate both checks in CI, and re-run them on every release, because new endpoints appear every week.

Is an unauthenticated endpoint always a vulnerability?

No. Health checks, documentation, and public marketing data should be public. The finding is when an endpoint that reads private data or changes state skips the check. The safe pattern is default-deny: everything requires authentication unless someone explicitly marks it public.

Related reading: The Email Finding We Keep Reporting — the other issue that shows up in nearly half of our assessments, and the four-step fix.