Almost every modern application is a thin client in front of an API. The web app in the browser and the app on the phone are, from a security point of view, untrusted code running on someone else's device, and everything that actually matters — the data, the business rules, the money — sits behind an API. That makes the API the real attack surface, and it is the part that is most often under-protected, because the visible front end gets the attention while the backend quietly assumes the front end will behave. It will not. This is a practical guide to securing the API behind your apps, written from the experience of building and reviewing them.
Problem Statement
The fundamental mistake in API security is trusting the client. A web front end can be inspected, modified, and bypassed entirely; a mobile app can be decompiled and its traffic intercepted. Any check that exists only in the client is no check at all, because an attacker simply talks to the API directly and skips it. Yet a great many APIs are built as though requests will only ever come from the official app, behaving themselves, sending well-formed data, and asking only for what they are entitled to.
The consequence is a class of vulnerability that does not show up in normal use and is trivial to exploit deliberately: an endpoint that returns another customer's data if you change an ID, an action that succeeds even though the user should not be allowed to perform it, a field that should never have been writable being written. These are not exotic attacks; they are the most common cause of real breaches, and they come from the API trusting what it should verify.
Industry Challenges
- Trusting the client — Controls placed in the front end are bypassed by talking to the API directly, yet this remains the most common design error.
- Broken authorisation — The single most prevalent serious API vulnerability: the API checks who you are but not whether you are allowed to access this particular thing.
- Over-exposure — Endpoints that return more data than the screen needs, or accept more fields than they should, hand attackers material and openings.
- Inconsistent enforcement — Security applied endpoint by endpoint inevitably has gaps; one forgotten check is a breach.
The Controls That Matter
Authentication and, more importantly, authorisation
Authentication establishes who is making a request; authorisation establishes what they are allowed to do, and it is where most breaches happen. The critical rule is that every request must verify not just that the user is logged in but that they are entitled to the specific resource they are asking for. An endpoint that returns an order by its ID must confirm the order belongs to the requesting user, every time, on the server. This sounds obvious and is violated constantly, because it is easy to write an endpoint that fetches by ID and forgets to check ownership.
Validate everything that arrives
Every piece of input — the body, the parameters, the headers — must be treated as hostile and validated on the server against a strict definition of what is acceptable. This prevents injection attacks, where malicious input is interpreted as a command, and it prevents the subtler problem of accepting fields the client should not be allowed to set. Validation in the client is for user convenience; validation on the server is for security, and only the latter counts.
Expose the minimum
An endpoint should return only the data the consumer legitimately needs and accept only the fields it should be allowed to change. Returning a whole record because it is convenient leaks data the screen never shows; accepting a whole object because it is easy lets an attacker set fields like a role or a price. Designing endpoints around what is needed rather than what is handy closes a large category of vulnerability.
Rate limiting and abuse protection
APIs need protection against being hammered, whether to guess passwords, scrape data, or simply overwhelm the service. Rate limiting, sensible lockouts, and monitoring for abnormal patterns are what stand between an exposed endpoint and an automated attack running against it at scale.
Implementation Considerations
Enforcement must be consistent, which means security cannot be sprinkled endpoint by endpoint where it is bound to be forgotten in one place. A structured backend framework helps here, because it lets authentication and authorisation be applied as a consistent layer that every request passes through rather than as a per-endpoint afterthought. This is one of the quiet advantages of building on a framework like NestJS rather than assembling a backend ad hoc.
Secrets — the keys and credentials the backend uses to reach databases and third-party services — must never be in the client, where they can be extracted, and must be stored and rotated properly on the server. Transport must be encrypted everywhere, with no exceptions for internal traffic that an attacker who gets inside could read. And for mobile specifically, remember that certificate pinning and obfuscation raise the bar but do not make the client trustworthy; the server must still verify everything.
On cost and scalability, good security is far cheaper designed in than bolted on after an incident, and the controls described here add negligible runtime cost while preventing the breaches that are genuinely expensive. The discipline of verifying rather than trusting is also exactly the kind of thing that generated code gets wrong, which we discussed in our piece on QA in the age of AI-generated code; an API assembled quickly from AI suggestions needs careful review of precisely these authorisation and validation checks.
Real-World Use Cases
- Multi-tenant SaaS — Where one customer must never see another's data, making per-request ownership checks the central security concern.
- Mobile apps handling personal or financial data — Where the decompilable client makes server-side verification non-negotiable.
- Public or partner APIs — Where external consumers make authentication, authorisation, rate limiting, and minimal exposure essential.
- E-commerce backends — Where writable fields like price and quantity must be strictly controlled to prevent manipulation.
Common Mistakes to Avoid
- Trusting the client — Any check that exists only in the front end is no check; an attacker talks to the API directly.
- Checking identity but not entitlement — The most common serious flaw: confirming who the user is but not whether they may access this specific resource.
- Accepting whole objects — Letting the client send a full object lets it set fields it should never control, such as roles or prices.
- Returning more than the screen needs — Over-exposed endpoints leak data that is invisible in the app but plain in the response.
- Applying security per endpoint — Inconsistent enforcement guarantees a gap; security belongs in a layer every request passes through.
Future Trends
API security is shifting towards consistent, centralised enforcement and away from per-endpoint checks, as teams learn that gaps come from inconsistency. Automated scanning and continuous testing for the common API vulnerabilities are becoming standard parts of the pipeline rather than occasional audits. And as more applications add AI features that call APIs, securing the boundary between an AI agent and your systems — verifying that it acts only within the requesting user's permissions — is becoming a new and important front, one we touched on in our writing on connecting AI to real systems.
Why Businesses Should Act Now
API breaches are among the most common and most damaging security incidents, and the vulnerabilities behind them are well understood and entirely preventable. Regulators and customers alike now expect personal data to be properly protected, and the reputational and financial cost of a breach far exceeds the cost of preventing it. Building the right controls in while the application is being developed is far cheaper and more effective than discovering the gaps through an incident.
Conclusion
The security of your apps lives in the API behind them, and the controls that matter are unglamorous and well established: verify entitlement on every request, validate all input on the server, expose the minimum, enforce consistently, and never trust the client. The breaches that make the news almost always trace back to one of these being skipped. Getting them right is a matter of discipline and experience rather than exotic technology, and it is far cheaper than the alternative. We build and review secure backends as a matter of course, and we are glad to assess where yours stands.
Frequently Asked Questions
Why is the API the main attack surface?
Because the web and mobile front ends are untrusted code running on someone else's device. They can be inspected, modified, decompiled, and bypassed, so everything that matters — data, rules, money — must be protected at the API, which is where requests actually arrive.
What is the most common serious API vulnerability?
Broken authorisation: the API confirms who the user is but fails to check whether they are entitled to the specific resource they requested. Changing an ID in a request to access someone else's data is the classic example, and it is extremely common.
Is validating input in the app enough?
No. Client-side validation is for user convenience and is trivially bypassed by talking to the API directly. Only server-side validation, treating all input as hostile, provides security.
How do we keep security consistent across many endpoints?
By enforcing authentication and authorisation as a layer that every request passes through, rather than checking each endpoint individually. A structured backend framework makes this consistency much easier to achieve and maintain.
Does AI-generated backend code affect API security?
Yes. Generated code frequently reproduces insecure patterns and omits exactly the ownership and validation checks that matter most. Backends assembled quickly with AI assistance need careful human review of authorisation, input handling, and field exposure.
Can mobile measures like certificate pinning make the client trustworthy?
No. Pinning and obfuscation raise the effort required to attack the client but do not make it trustworthy. The server must still verify every request, because a determined attacker can work around client-side protections.