On this page
Why APIs need their own security work
An API is a direct doorway into your data and business logic. Unlike a web page, it has no visual layer hiding what’s possible: anyone who finds an endpoint can send it requests, change the parameters and see what comes back. Many API problems aren’t exotic attacks at all — they’re an endpoint that returns another customer’s record when the ID in the URL is changed, or a login endpoint that allows unlimited password guesses.
API security is about closing those gaps deliberately: confirming who is calling, checking what they’re allowed to do on every request, limiting how fast they can do it, and refusing input that doesn’t match what the API expects. No review can make a system perfectly secure, but a disciplined one removes the common, well-understood weaknesses that most abuse relies on.
Who needs it — and warning signs
- A SaaS startup preparing for a customer’s security questionnaire or a larger client’s vendor review.
- An e-commerce store whose mobile app talks to an API that was built quickly for launch.
- A clinic whose booking or patient API handles personal and health-related data.
- A real estate portal that has opened an API to brokers or listing partners.
- A manufacturer exposing order or pricing data to distributors.
Warning signs include a single API key shared by every client, keys that have never been rotated, secrets committed to a code repository, no rate limit on login or OTP endpoints, or error messages that reveal stack traces and database details.
What’s included
- Authentication appropriate to each consumer — OAuth 2.0, signed tokens or scoped API keys.
- Authorisation checks on every request, including object-level checks so users can reach only their own records.
- Scoped keys with rotation, so each client has only the access it needs and keys can be replaced without downtime.
- Per-client rate limiting, with stricter limits on sensitive endpoints like login and OTP.
- Strict input validation against a defined schema, rejecting unexpected fields and types.
- Secrets management — credentials moved out of code and config files into the server environment or a secrets manager.
- TLS everywhere, sensible CORS rules and error responses that don’t leak internals.
- A written report of what was reviewed, what was found and what was changed.
How we approach it
- Scope and authorisation. We agree in writing which APIs and environments are in scope. We test only systems you own or are authorised to have tested.
- Inventory. We list every endpoint, who calls it and what data it touches — including forgotten or undocumented ones.
- Review. Code, configuration and behaviour are checked against the OWASP API Security Top 10 risks.
- Fix. Issues are prioritised by impact and fixed, or handed to your team with clear guidance if they own the code.
- Verify and document. Fixes are re-checked, and the report records the final state for your records or a client’s review.
Standards we work to
The OWASP API Security Top 10 is our main checklist. It covers the risks that matter most in practice, such as broken object-level authorisation, broken authentication, excessive data exposure, missing resource limits and security misconfiguration. Alongside it we apply standard practice for OAuth 2.0 flows, token expiry, TLS configuration and logging of security-relevant events.
What affects timeline and cost
- The number of endpoints and distinct consumer types.
- Whether we’re securing a new API during development or retrofitting an existing one.
- Access to source code — reviewing code is faster and more thorough than testing from outside.
- How many issues need fixing, and whether we fix them or guide your team.
- Any specific requirements from your customers or industry.
Common mistakes
- Checking that a user is logged in, but not that the record they’re requesting belongs to them.
- Returning whole database objects and relying on the app to hide sensitive fields.
- One master key used by every client, impossible to revoke without breaking everything.
- No rate limits, which invites password guessing, OTP brute-forcing and scraping.
- Treating security as a one-off task rather than part of every release.
Frequently asked questions
Can you guarantee our API is completely secure?
No honest provider can. What we can do is remove the known, common weaknesses, document what was checked, and put controls like rate limits and monitoring in place so problems are caught early.
Do you do penetration testing?
We carry out defensive security reviews of systems you own, with written authorisation and an agreed scope. If you need a formal third-party penetration test for compliance, we can prepare your API for it and help fix the findings.
We have API keys in our code repository. What should we do?
Treat them as exposed. The keys should be rotated at the provider, moved into the server environment or a secrets manager, and removed from the repository going forward. We can handle this without service interruption.
Can you review an API someone else built?
Yes. With access to the code and a test environment, we review it against the OWASP API risks and give you a prioritised list of findings and fixes.
How often should API security be reviewed?
Whenever significant changes are made, and at regular intervals otherwise. Building checks into the release process is more effective than occasional large audits.
Talk to us about api security
Authentication, rate limiting, key rotation and protection against abuse.