API Security Basics: Authentication, Rate Limiting and Key Management

API Security Basics: Authentication, Rate Limiting and Key Management

APIs connect web apps, mobile apps, payment gateways, delivery partners and internal tools. They also expose business data and actions to the internet. A single poorly protected API endpoint can leak customer data or allow unauthorised orders and changes.

This guide covers the security basics every junior developer should apply to APIs on SME projects. None of it is exotic, but skipping any of it is a common cause of real incidents.

Black cables and wires connected to the back of modular LED display panels

Authentication: Who Is Calling?

Every non-public endpoint must verify the caller's identity. Common approaches include session cookies for web apps, tokens such as JWTs or opaque tokens for mobile and single-page apps, and API keys or OAuth for machine-to-machine integrations.

  • Use well-tested libraries and framework features rather than writing your own authentication
  • Send credentials only over HTTPS
  • Set sensible token expiry and support revoking tokens
  • Protect login endpoints against brute force attempts

For mobile apps, remember that anything shipped inside the app can be extracted. Do not embed secret keys in mobile code; route sensitive operations through your own server instead.

Authorisation: What Are They Allowed to Do?

Authentication confirms identity; authorisation checks permissions. A very common vulnerability is when an API lets a logged-in user access another user's data simply by changing an ID in the URL, such as /orders/1234 to /orders/1235.

  1. Check ownership or permission for every resource on every request.
  2. Apply checks on the server, never relying on the front end hiding buttons.
  3. Use role-based permissions for admin functions.
  4. Return only the fields the caller needs, not entire database records.
Rule: assume every request can be crafted by hand. If the server does not check it, it is not protected.

Admin endpoints deserve extra care. Put them behind stronger authentication, restrict them to staff accounts and consider limiting access by network or requiring two-factor authentication for administrators. Many breaches start with an admin function that was assumed to be hidden but was never actually protected.

Silver MacBook turned on

Validate Input and Limit Abuse

Validate all input on the server: types, lengths, formats and allowed values. Use parameterised queries or your framework's ORM to prevent SQL injection, and encode output properly to prevent cross-site scripting where API data is displayed.

Rate limiting restricts how many requests a client can make in a time window. It protects against brute-force attacks, scraping and accidental overload from buggy integrations. Apply stricter limits on sensitive endpoints such as login, password reset and OTP verification.

Limit request sizes and file uploads, and paginate list endpoints so a single request cannot pull your entire database.

Configure CORS deliberately. Allow only the domains that genuinely need to call your API from a browser, rather than allowing every origin by default.

Manage Keys and Secrets Properly

API keys for payment gateways, email services and cloud providers are valuable to attackers. Keep them out of source code and front-end bundles. Store them in environment variables or a secrets manager, use separate keys for development and production and restrict each key's permissions where the provider allows.

Rotate keys when staff or freelancers leave and immediately if a key may have been exposed. Our guide on environment variables and secrets management covers this in more detail. When integrating third-party APIs, follow their security guidance, as in our payment gateway integration basics.

Check old repositories and documentation for keys that may have been committed in the past. Secret scanning tools offered by code hosting platforms can detect exposed keys automatically.

Black and silver padlock in grayscale photography

Logging, Monitoring and Updates

Log authentication failures, permission denials, unusual traffic spikes and errors, without logging passwords, tokens or full card data. Set alerts for suspicious patterns so you notice attacks early rather than through customer complaints.

Keep frameworks and dependencies updated, since vulnerabilities in libraries are a frequent attack route. Review your API against a recognised checklist such as the OWASP API Security Top 10 periodically.

Security is part of everyday development, not a final step. Small habits applied consistently protect customer data and business reputation far better than a rushed audit after something goes wrong.

Write down a short incident plan too: who to contact, how to revoke keys, and how to inform affected users if data may have been exposed.

FAQ

Are API keys enough for security?

For server-to-server integrations, scoped keys over HTTPS can be adequate. User-facing APIs need proper user authentication and authorisation.

Should I use JWTs?

They are common and useful, but must be implemented carefully with expiry and validation. Framework session handling is often simpler for web apps.

How do I test API security?

Try accessing other users' resources, sending invalid input and exceeding limits. Automated security scanners can help too.

API security rests on a few fundamentals: authenticate every caller, authorise every resource, validate every input, rate-limit sensitive endpoints, protect secrets and monitor activity. Build these into every project from day one.