By 
APIs power most of what users see in modern applications, and they fail in remarkably consistent ways. The same handful of mistakes show up year after year, in different products and different teams, regardless of language or framework. Recognising the patterns helps developers avoid them and helps reviewers spot them quickly during code or security reviews.
Trusting Client-Side Validation
Browsers and mobile apps perform validation for usability, not for security. Anything checked only on the client gets bypassed by the simplest attacker, who sends requests directly to the API and skips the front end entirely. Yet developers regularly assume that fields validated in the user interface arrive at the server in valid form. Server-side validation has to repeat every check, with the assumption that the client may have been hostile from the start.
Inconsistent Authorisation Checks
Authorisation often gets implemented in middleware or controller-level decorators, which sometimes get applied inconsistently across endpoints. A single endpoint that forgets the decorator becomes the soft underbelly through which an attacker accesses everything. web application penetration testing that specifically maps every endpoint and tests authorisation across them catches these inconsistencies. The fix is usually a one-liner, but only after the missing check has been identified.
Trusting Object IDs from the Client
An API that accepts an object identifier from the client, looks up the object, and returns it without checking ownership produces broken object level authorisation. The pattern is so common it has its own entry in the OWASP API Top 10. Solutions range from explicit ownership checks on every lookup, to mapping client-side identifiers through a layer that ties them to the authenticated user, to using indirect references that prevent enumeration entirely.
Expert Commentary
Name: William Fieldhouse
Title: Director of Aardwolf Security Ltd
Comments: Authorisation flaws on APIs are by far the most common critical findings I report. The bug is not interesting technically. It is just an absence of a check that should have been there. The reason it persists is that nobody tests for it specifically until something goes wrong, and by then the bug has been in production for months.
Excessive Data in Responses
An API endpoint that returns the entire user record when only a name and email were needed quietly leaks information into client-side code, browser caches, and any logs that capture the response. Filtering at the front end does not help. The data has already left the server. Every endpoint should return only what it needs to return, ideally enforced by the data model itself rather than relying on developers to remember the rule each time.
Rate Limiting and Resource Controls
APIs without rate limiting become exposure to credential stuffing, scraping, denial of service through resource exhaustion, and brute force against any feature that accepts repeated input. Rate limits should apply at multiple layers: per IP, per user, per endpoint, and globally. vulnerability scanning services that exercises this layer surfaces the missing controls long before they get exploited at scale.
Mass Assignment and Hidden Fields
Frameworks that automatically bind request fields to model properties enable mass assignment attacks, where the client supplies fields they were never supposed to control. A user updating their profile slips in is_admin equals true, and the framework dutifully writes the property to the database. Modern frameworks usually offer strong parameter filtering or DTO patterns that prevent this. They have to be used. Using them by default avoids the entire class of bug.
Building Better Habits
Train developers on the patterns above, write code review checklists that look specifically for each one, and automate detection where possible through linting and security tools. Review every new endpoint against the same questions: Does it require authentication? Does it require authorisation? Does it validate input properly? Does it return only what it should? Apply this discipline consistently and most API security issues fade away before they ship.
Comments