<img src="https://securitypatterns.io/images/05-microservices/Diagrams-Sol-Outbound.png" alt="Image">
<img src="https://media2.dev.to/dynamic/image/width%3D1600%2Cheight%3D900%2Cfit%3Dcover%2Cgravity%3Dauto%2Cformat%3Dauto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F8wiw2dbjerzq6br66qv8.png" alt="Image">
<img src="https://bytebytego.com/images/courses/system-design-interview/design-a-rate-limiter/figure-4-13-G2VF2RCQ.png" alt="Image">
<img src="https://miro.medium.com/v2/resize%3Afit%3A1400/1%2AnBXfm6BcTvyfPf0f9MJ_-Q.jpeg" alt="Image">
Here’s a scary thought: every API you deploy is public unless you actively make it private.
Not “public” as in Google-indexed — public as in reachable, callable, and attackable.
Most backend breaches don’t come from elite hackers. They come from bored scripts, leaked tokens, or endpoints you forgot existed. Let’s walk through the most common API security mistakes I still see in production—and how to harden your backend without turning it into a usability nightmare.
<hr>
<h2>1. “We Have Auth” Is Not a Security Strategy</h2>
Authentication answers who you are.
Authorization answers what you’re allowed to do.
Many APIs stop at auth.
<pre><code class="language-http">GET /api/users/123
Authorization: Bearer &lt;valid-token&gt;
</code></pre>
If the token is valid, the request succeeds — even if the user shouldn’t see that data.
<h3>The fix: enforce ownership and roles everywhere</h3>
<pre><code class="language-ts">// ❌ Only checks auth
if (!req.user) throw new UnauthorizedError();

// ✅ Checks authorization
if (req.user.id !== params.userId &amp;&amp; !req.user.isAdmin) {
 throw new ForbiddenError();
}
</code></pre>
Security rule of thumb:
Every read, write, and delete must answer “why is this user allowed?”
<hr>
<h2>2. JWTs Are Not Magic Shields</h2>
JWTs are great. Misused JWTs are dangerous.
Common issues:
<ul>
<li>No expiration (<code>exp</code>)</li>
<li>Tokens stored in <code>localStorage</code></li>
<li>Tokens accepted forever after user logout</li>
<li>No audience (<code>aud</code>) or issuer (<code>iss</code>) validation</li>
</ul>
<h3>Minimum safe JWT setup</h3>
<pre><code class="language-ts">const payload = jwt.verify(token, JWT_SECRET, {
 audience: &#x27;api.myapp.com&#x27;,
 issuer: &#x27;auth.myapp.com&#x27;,
});
</code></pre>
Also:
<ul>
<li>Short-lived access tokens (5–15 min)</li>
<li>Refresh tokens stored httpOnly</li>
<li>Token rotation on refresh</li>
</ul>
JWTs don’t make you secure — your validation logic does.
<hr>
<h2>3. Rate Limiting Isn’t Optional Anymore</h2>
If your API has:
<ul>
<li>Login</li>
<li>OTP</li>
<li>Password reset</li>
<li>Search</li>
<li>Public endpoints</li>
</ul>
…it needs rate limiting. Period.
Without it:
<ul>
<li>Brute-force attacks are trivial</li>
<li>Scrapers will eat your bandwidth</li>
<li>One bad client can DOS your system</li>
</ul>
<h3>Simple rate limit example</h3>
<pre><code class="language-ts">import rateLimit from &#x27;express-rate-limit&#x27;;

export const limiter = rateLimit({
 windowMs: 60 * 1000,
 max: 100, // requests per minute
});
</code></pre>
Apply different limits for:
<ul>
<li>Auth endpoints</li>
<li>Public APIs</li>
<li>Internal services</li>
</ul>
Security isn’t about blocking users — it’s about controlling abuse.
<hr>
<h2>4. Overexposed Data (aka Accidental Leaks)</h2>
This is the most common real-world breach I see.
Example:
<pre><code class="language-json">{
 &quot;id&quot;: 42,
 &quot;email&quot;: &quot;user@example.com&quot;,
 &quot;passwordHash&quot;: &quot;...&quot;,
 &quot;isAdmin&quot;: false,
 &quot;createdAt&quot;: &quot;...&quot;
}
</code></pre>
Nobody meant to expose <code>passwordHash</code>.
It just happened.
<h3>Fix: explicit response contracts</h3>
<pre><code class="language-ts">// ✅ Safe DTO
return {
 id: user.id,
 email: user.email,
 createdAt: user.createdAt,
};
</code></pre>
Never rely on:
<ul>
<li>ORM default serialization</li>
<li><code>res.json(entity)</code></li>
<li>“We’ll filter it on the frontend”</li>
</ul>
If you didn’t whitelist it, it shouldn’t leave the server.
<hr>
<h2>5. CORS Is Not an Auth Mechanism</h2>
I still hear:
<blockquote>
“It’s safe, our CORS is locked down.”
</blockquote>
CORS only affects browsers.
Attackers don’t use browsers.
<pre><code class="language-bash">curl https://api.yoursite.com/secret
</code></pre>
CORS doesn’t stop:
<ul>
<li>Server-to-server calls</li>
<li>Bots</li>
<li>Mobile apps</li>
<li>Postman</li>
<li>Curl</li>
</ul>
<h3>What CORS is for</h3>
<ul>
<li>Preventing malicious websites from abusing your users’ browsers</li>
</ul>
<h3>What it’s not for</h3>
<ul>
<li>Protecting your API</li>
</ul>
You still need auth, authorization, and rate limiting.
<hr>
<h2>6. Secrets in the Wrong Places</h2>
If your repo ever contained:
<ul>
<li><code>.env</code> files</li>
<li>API keys</li>
<li>Firebase configs</li>
<li>AWS credentials</li>
</ul>
…assume they’re compromised.
<h3>Rules that save careers:</h3>
<ul>
<li>Secrets only in environment variables</li>
<li>Rotate keys regularly</li>
<li>Never log secrets (even in debug)</li>
<li>Scope keys to the minimum permissions</li>
</ul>
If a key leaks, your blast radius should be tiny, not existential.
<hr>
<h2>7. Missing Audit Trails</h2>
When something goes wrong, you need answers:
<ul>
<li>Who did this?</li>
<li>When?</li>
<li>From where?</li>
<li>Using which token?</li>
</ul>
If you don’t log security-relevant actions, you’re blind.
Log:
<ul>
<li>Auth attempts</li>
<li>Permission failures</li>
<li>Admin actions</li>
<li>Token refreshes</li>
<li>Role changes</li>
</ul>
Not verbosely. Intentionally.
<hr>
<h2>8. “Internal” APIs Are Still APIs</h2>
Microservices make this worse.
Just because an endpoint is:
<ul>
<li>Behind a VPC</li>
<li>On a private subnet</li>
<li>“Only called by services”</li>
</ul>
…doesn’t mean it’s safe.
<h3>Protect internal APIs with:</h3>
<ul>
<li>Service-to-service auth</li>
<li>Short-lived tokens</li>
<li>Network-level rules</li>
<li>Explicit permissions</li>
</ul>
Zero trust isn’t paranoia — it’s realism.
<hr>
<h2>Key Takeaway</h2>
API security isn’t one feature.
It’s a collection of boring, disciplined decisions:
<ul>
<li>Explicit authorization</li>
<li>Minimal data exposure</li>
<li>Rate limits everywhere</li>
<li>Short-lived credentials</li>
<li>Clear audit logs</li>
</ul>
Most breaches don’t come from sophisticated exploits.
They come from defaults you forgot to change.

Frozen Blood

APIs are publicly accessible by default and vulnerable to attacks through leaked tokens, forgotten endpoints, and misconfigured security. Common mistakes include treating authentication as sufficient security without proper authorization checks, misusing JWTs without expiration or validation, lacking rate limiting on critical endpoints, accidentally exposing sensitive data in responses, misunderstanding CORS as an authentication mechanism, storing secrets in repositories, missing audit trails for security events, and leaving internal microservice APIs unprotected. Effective API security requires disciplined practices: explicit authorization on every operation, minimal data exposure through whitelisted responses, comprehensive rate limiting, short-lived credentials, clear audit logging, and zero-trust architecture even for internal services.

Your API Is Public by Default — Let’s Fix That