Hacker vs Azure Defences: Five Attacks on a Mobile Backend, Five Controls

Five common attacks on a mobile backend map onto five Azure controls: Front Door WAF for junk traffic, Entra ID for missing tokens, an owner check for a valid token asking for someone else’s data, Key Vault for leaked keys, and a private endpoint for direct database access. Miss one and the other four do not cover for it.

Five attacks on the same Azure backend. Five named things that stop them.

What stops junk traffic and injection strings?

Stopped by: Azure Front Door WAF, running the OWASP managed ruleset at the edge. Traffic blocked here costs nothing downstream. No container starts. No database connection opens.

The catch: WAF ships in Detection mode, and Detection only logs. Switch it to Prevention.

What stops a call with no token?

Stopped by: Microsoft Entra ID. Your API validates the signature, issuer and audience against Microsoft’s published keys. It is a local check, so it costs microseconds, not a round trip.

The catch: validate the aud claim, not just the signature. A valid token issued for a different app is still a valid token.

A real token, and someone else’s id

This is the one people miss. The attacker signs in legitimately as themselves, then requests GET /orders/1043, which belongs to someone else. Authentication passed. Nothing is wrong with their token.

Stopped by: an owner check in your API. The failure is called broken object level authorization, and it is number one on the OWASP API Security Top 10.

db.Orders.Where(o => o.UserId == me.GetObjectId())

Take the user id from the validated token. Never from the body, the query string or a header. The moment the client can tell you who it is, the check is decoration.

Searching your public repo for keys

Stopped by: Azure Key Vault plus a managed identity, so the repo holds a vault URI and nothing else. Also turn on GitHub secret scanning, and check history as well as the working tree. A key removed in a later commit is still in the repo. The blast-radius article covers what rotating one costs.

Dialling the database directly

Stopped by: a private endpoint, with public network access set to Disabled. The server gets a private IP inside your VNet. It has no internet-facing address at all.

The Azure default that undoes the private endpoint

“Allow Azure services and resources to access this server” sounds like it means your Azure resources. It does not. It means any resource in any Azure subscription in the world, including one an attacker spins up in five minutes. Leave it off.

What to check this week

1. Is WAF in Prevention or Detection?
2. Can you fetch another user’s record with your own valid token?
3. Is public network access Disabled on SQL, Storage and Key Vault?
4. Is “allow Azure services” off?
5. Is Microsoft Defender for Cloud on, so you find out before the invoice does?

Miss one of the five doors and the other four do not cover for it. The five-layer request flow makes the same point for the layers; this is it applied to named attacks.

Key takeaways

• Five common attacks map onto five Azure controls: WAF, Entra ID, an owner check in your own code, Key Vault, and a private endpoint.
• Owner checks are the control authentication cannot provide. A real, valid token is exactly what a broken-object-level-authorization attack uses.
• WAF’s default Detection mode only logs. Switch it to Prevention.
• “Allow Azure services and resources” covers every Azure tenant, not yours. Keep it off.
• Run the five-question audit on a schedule, not once.