When working with APIs, it's important to understand the difference between normal API consumption and unauthorized access.
A typical application might fetch data from an API like this:
fetch("https://api.example.com/data", {
headers: {
"Authorization": "Bearer YOUR_TOKEN"
}
})
.then(response => response.json())
.then(data => console.log(data));
The important part is that the server controls access. The frontend can request data, but the API should verify authentication and authorization before returning anything sensitive.
This becomes interesting when looking at how crackers attack poorly protected APIs.
For example, a badly designed API might expose an endpoint such as:
GET /api/user/123
without properly checking whether the requesting user is actually allowed to access user 123.
A malicious user could then change the ID:
/api/user/124
/api/user/125
/api/user/126
and potentially access information belonging to other users.
This is a classic example of an authorization problem, often associated with IDOR (Insecure Direct Object Reference).
The lesson isn't that fetch() itself is dangerous. The problem is trusting requests without validating them on the server.
Developers should consider:
Authenticate every protected request.
Authorize access to each resource server-side.
Never rely on hidden frontend fields for security.
Validate user-supplied IDs and parameters.
Avoid exposing sensitive information through public endpoints.
Rate-limit suspicious requests.
Log and monitor unusual API activity.
API security ultimately comes down to one principle:
Never assume that because your frontend hides something, a user cannot send that request manually.
The browser is only a client. Your server must enforce the rules.
What API security issue have you encountered that taught you an important lesson?
Top comments (0)