API Security Basics: Rate Limiting, Authentication, and Common Mistakes

Most API security incidents don't come from an exotic zero-day - they come from a handful of well-known mistakes that show up constantly because they're easy to skip under deadline pressure and don't announce themselves until someone abuses them.

Rate Limiting

An API with no rate limit lets a single client - malicious or just a buggy retry loop - make unlimited requests. Beyond the obvious denial-of-service risk, unrated endpoints are what make credential-stuffing and brute-force attacks against login/password-reset endpoints practical at scale in the first place.

• Rate limit by a meaningful key - IP address alone is weak (easily rotated), pairing it with an account identifier or API key is stronger.
• Return 429 Too Many Requests with a Retry-After header so well-behaved clients back off correctly instead of hammering the endpoint harder.
• Apply tighter limits specifically to sensitive endpoints (login, password reset, token issuance) than to general read endpoints.

Authentication Mistakes

• API keys with no scoping. A single key that can do everything means a leaked key is a full account compromise, not a contained incident.
• No expiration or rotation path.A key issued once and never expiring is a permanent liability the moment it's ever exposed - in a log, a client-side bundle, a public repo.
• Sensitive data in URLs. A token or key passed as a query parameter ends up in server access logs, browser history, and referrer headers - anywhere a header would have kept it out.

CORS Misconfiguration

A wildcard Access-Control-Allow-Origin combined with Access-Control-Allow-Credentials: trueis one of the most common critical API misconfigurations - it lets any website read authenticated responses from your API on a logged-in user's behalf.

Input Validation and Injection

An API endpoint is just as exposed to SQL injection, command injection, and similar attacks as a traditional web form - arguably more so, since APIs are often tested less thoroughly by hand than user-facing pages. Validate and parameterize on the server regardless of what client-side validation already ran, since an API can always be called directly, bypassing any frontend checks entirely.

A Reasonable Baseline

• Rate limits on every endpoint, tighter on auth-related ones.
• Scoped, expiring, rotatable API keys - never a single permanent all-access key.
• An explicit CORS allowlist, never a wildcard paired with credentials.
• Server-side validation on every input, regardless of what the client already checked.