DEV Community

Prajwal Gaonkar
Prajwal Gaonkar

Posted on

You Can’t Secure Public APIs — You Can Only Control Them

#api #backend #security #webdev

While building my public form system, I initially thought security meant restricting frontend access, using tokens, and enabling CORS.

But after going deeper, I realized something fundamental: I was securing the frontend… not the API.

Attackers don’t use your frontend. They don’t click buttons. They go straight to your API.

1. The CORS Illusion

I assumed CORS would protect my API. But CORS is a browser-only safety rail. It does NOT block requests; it only blocks browsers from reading responses.

This still works perfectly:
curl https://your-api.com/submit

The Reality: Your backend still executes logic. Your database can still be modified. CORS protects users, not your server.

2. Tokens Are Not Enough

I implemented CSPRNG tokens and one-time validation. This made tokens unguessable, but it didn't make them restricted.

If your token endpoint is public, anyone can do:
curl https://your-api.com/get-token

The issue wasn’t token security. It was token issuance.

3. The Shift to Token Binding & DBSC

The idea of Token Binding is that a token should only be usable by the client that received it.

In 2026, we’ve moved past the old TLS Token Binding (which browsers like Chrome removed) to DBSC (Device Bound Session Credentials).

How DBSC Works:

  1. Hardware Key: The device generates a key pair in the TPM (Security Chip).
  2. Binding: The server binds the session token to the public key.
  3. Proof: Every request must be signed by that hardware key.

Does this stop a CLI attacker?

  • Case 1 (Token Theft): Attacker steals your token. They can't sign the request without your hardware. SUCCESS.
  • Case 2 (The CLI "Guy"): The attacker uses their own CLI to generate a key, gets a token, and signs the request. FAILURE.

Insight: DBSC prevents misuse, not malicious usage.

4. The Real Solution: Zero Trust

If you cannot stop a CLI attacker from acting like a valid client, you must change your mindset: Assume every request is malicious until proven otherwise.

You don't secure public APIs by blocking access; you secure them by controlling behavior.

5. The "One-Stop" System Design

To protect a public form, you need a layered pipeline that makes abuse expensive and slow.

The Defensive Pipeline:

  1. Rate Limiting: Control the volume.
  2. JS Challenge / Turnstile: Stop simple CLI scripts that can't execute JavaScript.
  3. TLS Fingerprinting (JA4): Identify if the "handshake" comes from a browser or a library like curl.
  4. Token Issuance Control: Only issue tokens after the challenge is passed.
  5. Idempotency: Ensure the same "attack" packet can't be processed twice.

6. Key Techniques for 2026

  • Reject Early: Do cheap checks (IP Rate Limits) before expensive checks (DB lookups).
  • Context Binding: Bind tokens to the IP and User-Agent. If they change mid-session, kill the token.
  • Make it Expensive: Force attackers to use residential proxies and headless browsers (Puppeteer). When the cost of the attack exceeds the value of the data, the attacker leaves.

🔗 Code & Implementation

Check out the full implementation and experiments here:
👉 github.com/OP-Prajwal/publicForm

Top comments (0)