Singapore’s New API Warning Is a Reminder: Login Is Not Authorization

A customer is signed in, the API returns a record, and the application appears to work. The security question is the one hidden behind that successful response: did the server verify that this particular customer was allowed to see this particular record?

The Singapore PDPC and CSA’s 12 November joint advisory makes insecure APIs a current data-protection concern. Its public landing page states the subject and links the full advisory PDF. The agencies’ announcement does not describe a named breach or quantify affected organizations, so the important takeaway is the control problem itself: APIs can expose personal data when authorization is incomplete or inconsistently applied. [^[1] ]

A login check answers only half the question

Imagine a clinic portal with an endpoint like /records/4821. The server may confirm a user has a valid session, then fetch record 4821. If it never checks whether that user is the patient, clinician or administrator entitled to see it, the session check has not protected the record. Changing the number might reveal someone else’s information. This is commonly called broken object-level authorization, or BOLA; older discussions often call the pattern IDOR.

The bug is easy to miss because every individual component can appear correct. The browser hides links. The identifier is difficult to guess. The endpoint requires a login. Yet attackers do not need to use the intended interface, and identifiers are not access controls. OWASP’s API Security Top 10 places broken object-level authorization first and recommends an authorization check wherever an API uses a client-controlled identifier to access data. [^[2] ]

A safe pattern binds the requested object to the caller’s permitted scope inside the data access itself. For a customer account, that may mean querying by both record ID and the authenticated account’s tenant ID. For a clinician, the rule may require an active care relationship. The exact policy depends on the product; the invariant is that the server derives identity from verified credentials and enforces the relationship for every operation.

The same object can leak through another door

Teams often test only the detail-page GET. But a record may also appear in search, exports, bulk endpoints, background jobs, file downloads, comments, activity feeds or nested resources. A read check does not automatically protect update, delete or sharing operations. Nor does authorization at the parent object guarantee that every child field is safe to return.

That is why the agencies’ API warning should prompt an inventory exercise, not a one-line patch. List routes that return or mutate personal data, identify the object and tenant boundaries each route uses, and document which roles can perform each action. Include older versions, mobile endpoints, partner integrations and endpoints no longer linked from the current interface. OWASP separately calls out property-level authorization and function-level authorization because access to an object and access to every field or operation are different decisions. [^[2] ]

A practical test that catches the quiet failure

Create two test users with deliberately different access. As user A, request A’s record and confirm success. Then substitute B’s identifier in the path, query string, body, nested object or batch list. The expected result is a denial or a response that reveals no protected data. Repeat for update and deletion, not just reads. Finally test an authorized user with a restricted role to ensure field-level rules hold.

This is not a recommendation to probe production customer records. Use isolated fixtures or a staging dataset. Add the test to the service’s authorization suite and run it against every route that accepts object identifiers. A central policy helper can reduce drift, but it is not proof by itself: developers still need to call it consistently, and the policy needs tests that exercise real handler paths.

Inventory and lifecycle matter too

An API can remain exposed after the team that owned it has moved on. New mobile clients can preserve old versions; middleware migrations can leave orphaned routes; third-party connections can retain broad scopes. Record the owner, data classes, authentication method, authorization rule, version and retirement plan for each API. When a service changes hands or is replicated, verify that its protections moved with it.

Monitoring helps find mistakes that tests missed. Alert on unusual object-access patterns, repeated denials, bulk enumeration and access outside normal role or tenant boundaries. Logs should capture enough to investigate the decision without copying sensitive personal data into the log itself. Rate limits help with abuse and resource use, but they do not repair an authorization flaw: a slow leak is still a leak.

What teams can do this week

Start with the most sensitive records and the endpoints that accept caller-supplied IDs. Confirm that authorization is evaluated server-side for each request and each action. Test across two identities, then review batch, export and legacy routes. Update the API inventory and assign owners for exceptions. If a check fails, contain access, preserve relevant logs, assess whether personal information may have been exposed, and follow the organization’s applicable incident and notification process.

The joint advisory is a useful prompt, not evidence that every API is vulnerable or that a specific incident occurred. The durable lesson is concrete: “user is authenticated” and “user may access this object” are separate statements. Systems that keep them separate can test, audit and improve the rule that actually protects each record.

For a related security perspective, see our guide to approved tools used in intrusions and what an exposed credential can—and cannot—prove.