Singapore’s PDPC and CSA Warn on Insecure APIs: Nine Measures to Stop Quiet Data Leaks

Most large data leaks no longer start with someone breaking down the front door. They start with an API that answers questions it should not, using credentials that look perfectly legitimate. Singapore’s Personal Data Protection Commission (PDPC) and Cyber Security Agency (CSA) addressed that problem directly on November 12, 2026, with a joint advisory on data protection risks arising from insecure application programming interfaces. The advisory sets out five risk areas and nine recommended measures, and it ties API security explicitly to the legal duty to protect personal data under Singapore’s Personal Data Protection Act (PDPA).

What Singapore published

The document is titled the Joint Advisory on Data Protection Risks Arising from Insecure APIs. Some summaries described it as guidance on “API security standards.” It is more accurately an advisory: it does not create a new technical standard or a certification scheme. Instead, it explains how organisations should apply their existing obligation under section 24 of the PDPA, which requires reasonable security arrangements to protect personal data in their possession or under their control, to APIs specifically.

The advisory also says its measures reinforce the PDPC’s Guide to Data Protection Practices for ICT Systems, which was revised on July 20, 2026. For organisations already using that guide, the API advisory works as a focused supplement. It is not the first time Singapore has addressed the subject. The CSA issued a general advisory on securing APIs in October 2022. The difference now is that the privacy regulator is co-signing and framing the issue as a personal data problem, not only a cybersecurity one.

Why APIs worry regulators

APIs let a website or mobile app retrieve customer information from a database, and they let third-party service providers access the data they need. The advisory notes that attackers can use these same channels to pull out large volumes of personal data, often without detection, because requests appear to come from authorised users or applications.

The advisory points to two PDPC enforcement cases. In the Marina Bay Sands case, a misconfigured API endpoint and weak default credentials allowed a threat actor to access and exfiltrate personal data of about 665,495 individuals. In the Tech in Asia case, a legacy API endpoint that did not verify authorisation tokens was exploited to scrape data on about 220,000 people. Readers who want the legal background on what happens after such an incident can see our guide to a breach of the PDPA in Singapore.

Two illustrative scenarios in the advisory will feel familiar to security teams:

• Case A: An internet-facing API protected only by weak default credentials let researchers systematically query a database of millions of records. Nobody noticed, because the queries used legitimate functions and valid credentials.
• Case B: Internal API endpoints became reachable from the internet after a network restriction was removed to accommodate a third-party integration. No replacement safeguard was added, and the organisation did not know it was exposed.

Case B is a third-party risk story as much as a technical one. Vendor integrations are a frequent cause of exposure, as large incidents such as the McGraw Hill breach tied to Salesforce governance gaps and the IDScan breach that rippled through its customers have shown.

The five risk areas

• Unintended exposure. APIs that are poorly designed or return more data than needed, and internal APIs that become internet-accessible after updates, migrations or third-party changes.
• Default authentication and credential management. Default or poorly managed credentials, and API keys or tokens stolen through compromised accounts or third-party apps. The advisory warns that successful authentication alone may not stop unauthorised access.
• Inadequate access controls and authorisation. Excessive privileges and weak authorisation checks, including Broken Object Level Authorisation (BOLA), where a logged-in user can retrieve another person’s record by changing an identifier. BOLA is listed first in the OWASP API Security Top 10 (2023).
• Inadequate security configurations. Settings omitted or removed during migrations, unencrypted connections exposed to man-in-the-middle attacks, and missing input validation that allows injection attacks.
• Inadequate logging and monitoring. Without good logs, repeated requests that quietly drain data can continue for a long time.

The nine recommended measures

The advisory’s recommendations, in its own order, are a useful checklist for any organisation that exposes or consumes APIs carrying personal data:

1. Maintain visibility over APIs. Keep an up-to-date inventory of APIs that process personal data, covering purpose, owner, data types, how data is exchanged and which third parties have access. Remove obsolete APIs. This fits naturally into a broader data inventory.
2. Minimise personal data exposure. Make sure each API returns only the data needed for its purpose and restrict access to sensitive fields.
3. Implement security configurations and access controls. Use frameworks such as the OWASP API Security Top 10, OWASP cheat sheets and the CIS API Security Guide. Keep internal APIs off the internet, enforce object-level authorisation, apply least privilege to users, applications and vendors, encrypt traffic with HTTPS and TLS, validate inputs server-side and consider a web application firewall.
4. Protect API credentials. Use strong non-default passwords, multi-factor authentication for privileged access, secure storage of keys and tokens outside source code and public files, and fast revocation.
5. Strengthen change management. Test security before and after changes, automate deployments where practical, and risk-assess any removal of a control, including for third-party integrations, before it happens.
6. Assess and test. Test APIs before deployment, periodically and after significant changes, and verify that fixes work.
7. Log and monitor. Record who made requests, when, which functions were used and, where appropriate, how much data was retrieved. Higher-risk systems should alert on unusual volumes, sequential access to different customers’ records or large exports, including from valid credentials.
8. Guard against excessive extraction. Use rate limiting, caps on records per request and export thresholds. The advisory stresses these complement, and do not replace, access control and monitoring.
9. Prepare incident response. Include procedures to revoke compromised credentials, suspend suspicious access and assess whether personal data was affected, run API-specific tabletop exercises, and consider notification duties under the PDPA. The CSA’s Incident Response Checklist is recommended as a high-level guide.

Several of these measures match a broader shift toward data-centric zero trust, where every request is checked against what data the caller should see, not just whether it holds a valid key.

What it means for privacy and vendor risk teams

An advisory is not law, but it signals what the PDPC will treat as “reasonable security arrangements” when it investigates a breach. An organisation that suffers an API leak after ignoring these points will find it harder to argue that its safeguards were adequate. Where a breach is notifiable, the PDPA requires notice to the PDPC as soon as practicable and no later than three calendar days after the organisation assesses it as notifiable.

For third-party risk management, the advisory gives procurement teams concrete questions to ask vendors that connect through APIs:

• Do you maintain an inventory of APIs that touch our customers’ data, and can you share it?
• How do you test for object-level authorisation flaws, and how often?
• How are API keys and tokens stored, rotated and revoked?
• What logging and alerting do you have for unusual extraction, including by authenticated clients?
• Do you risk-assess integrations that require relaxing network controls?

The advisory ends by noting that API security is not a one-off exercise. New systems, updates, changes to integrations and new vulnerabilities can all reopen risks. Data protection officers are encouraged to work with IT teams and service providers, and small businesses can look at government cybersecurity assistance schemes.

Frequently asked questions

Is the advisory binding?

No. It is guidance on how to meet the PDPA’s existing protection obligation, which is binding. The PDPC can take enforcement action when security arrangements fall short.

Does it apply to APIs we consume from vendors, or only ones we build?

Both. The protection obligation covers personal data in your possession or under your control, and the advisory specifically addresses third-party service providers and integrations.

Is rate limiting enough to prevent scraping?

No. The advisory treats rate limits and export thresholds as an extra layer that must sit on top of proper authorisation and monitoring.

We are not in Singapore. Is this relevant?

The measures align with OWASP and NIST practice, so they make a sensible baseline anywhere, and they apply directly if you process personal data of people in Singapore.

Close the side doors

Singapore’s regulators have stated plainly that a valid key is not the same as permission. Organisations that can list every API touching personal data, show who can see what through it, and spot when someone is quietly pulling too much will meet the PDPC’s expectations, and will be better protected wherever they operate.