API security in India: close the leaks in your APIs, keys and code supply chain

Most products today are a set of APIs with a mobile app or a web front end on top. Those APIs carry the personal data: names, phone numbers, addresses, orders, health reports, payment references. When they fail, they tend to fail quietly. Nothing crashes. The API simply returns data to someone who should not have it, and you find out from a customer, a researcher or a log review months later.

This page explains where API and software supply chain risks come from, how they map to the DPDP Act and Rules, and how our API security engagement runs. We are an engineering, security and privacy team. We work alongside your legal counsel, who advise on legal questions such as breach notice.

Why do APIs leak personal data?

The OWASP API Security Top 10 (2023 edition), a widely used open reference, puts broken object level authorisation first (API1:2023). It also lists broken authentication (API2), broken object property level authorisation (API3), broken function level authorisation (API5), security misconfiguration (API8), improper inventory management (API9) and unsafe consumption of APIs (API10). In plain terms, the repeated patterns are:

• No ownership check. The API trusts the record ID in the request and does not confirm it belongs to the caller.
• Too much in the response. The API returns the full database object and leaves the app to hide fields, so date of birth, address or internal notes travel to every phone.
• Admin functions open to ordinary users. An endpoint meant for staff works for any logged-in user who finds it.
• Forgotten APIs. An old version, a partner integration or a test server still runs, still holds real data, and has none of the newer controls.
• Leaked secrets. A cloud key, database password or third-party token is committed to a repository, pasted in a ticket or printed in a build log.
• Compromised or outdated components. A library or base image you build on has a known vulnerability, or a malicious version enters your build.

CERT-In's Technical Guidelines on SBOM, QBOM and CBOM, AIBOM and HBOM (Version 2.0, dated 9 July 2025) name the same supply chain threats: malicious code inserted by attackers, vulnerabilities in outdated components, and breaches through compromised suppliers.

What does DPDP require of API and supply chain security?

The DPDP Act does not mention APIs, SBOMs or pipelines. It sets outcomes. Section 8(5) requires a Data Fiduciary to take reasonable security safeguards to prevent a personal data breach. Rule 6 of the DPDP Rules, 2025 sets the minimum measures, with examples introduced by “such as”. Both apply from 13 May 2027. The table shows how the Rule 6 measures translate into API and supply chain controls. The full control set is in our security safeguards guide.

Failing to take reasonable security safeguards can attract a penalty of up to ₹250 crore under the Schedule to the Act. The Board decides the amount after an inquiry, weighing factors in section 33(2) such as the gravity and duration of the breach and whether you took timely steps to mitigate it.

What is broken object level authorisation, and how do you fix it?

Broken object level authorisation (BOLA) happens when an API takes an object identifier from the caller, such as /orders/48213, and returns that object without checking that the caller is allowed to see it. Authentication is not enough: the caller is logged in, just not as the owner. Changing 48213 to 48214 returns a stranger's order, address and phone number.

The fix is a design rule, not a patch on one endpoint:

• Every handler that reads or changes a record checks ownership or permission on the server, using the identity from the session or token, never from a field the caller sends.
• The check lives in one shared layer that every endpoint uses, so a new endpoint cannot ship without it.
• Responses are built from an explicit list of fields for that caller, not by returning the whole object.
• Tests try each endpoint with a second user's identifiers, and the pipeline fails if any of them returns data.
• Monitoring flags a single account or key reading many records in sequence.

How does an API security engagement run?

We follow five steps. Each one produces evidence you can keep in your Rule 6 file. All testing happens only on systems you own or are authorised to test, under written authorisation that sets scope, timing and contacts.

1. Discover: every API, including forgotten ones

We build an inventory from your gateway and load balancer configuration, DNS records, cloud accounts, mobile app traffic, API specifications and code repositories. Each API is tagged with its owner, the personal data it carries, who calls it and whether it is still needed. Old versions and test servers holding real data are usually the first findings. Retiring an API is often cheaper than securing it.

2. Authenticate: strong auth, checks on every record, least privilege

We review how each API authenticates callers and how it decides what they may see. We test for broken object level, property level and function level authorisation using test accounts you provide. Service accounts and partner keys are cut back to the access they need. Where fixes are needed, our engineers work with yours on the shared authorisation layer rather than one endpoint at a time.

3. Protect secrets: vault and rotation, no keys in code

We scan repositories, including their history, along with build logs, container images and configuration for exposed keys and passwords. Exposed secrets are rotated, not just deleted, because a copy may already exist elsewhere. We help you set up secrets management: a vault, one credential per service, short lifetimes where the platform allows, rotation on a schedule, and access to the vault logged.

4. Know your components: SBOM and vulnerability scanning

We generate a software bill of materials for each application and container image: the libraries, versions, suppliers and licences it contains. CERT-In's guidelines list minimum SBOM data fields such as component name, version, supplier, licence, dependencies, vulnerabilities, patch status and end-of-life date. The SBOM feeds a vulnerability management process: scanning against known vulnerabilities, a fix timeline by severity, an owner for each finding and a record of what was fixed when.

5. Secure the pipeline: checks in CI/CD, signed builds

CI/CD security keeps the gains from slipping. We add checks to your build and release pipeline: secret scanning, dependency and image scanning, the authorisation tests from step 2, and a gate that blocks a release with critical findings. Pipeline credentials get least privilege, builds run from reviewed code, and release artefacts are signed so you can show what was deployed and where it came from.

Is an API data leak a reportable breach under DPDP?

Often, yes. Section 2(u) defines a personal data breach to include unauthorised processing and accidental disclosure, acquisition or sharing that compromises confidentiality. An API that served one person's record to another fits that description. Section 8(6) requires every personal data breach to be intimated to the Board and to each affected person, with no materiality threshold. Under Rule 7, the Board gets an initial intimation without delay and a detailed report within 72 hours of you becoming aware. CERT-In's separate 6-hour reporting direction (April 2022) continues to apply in parallel for reportable cyber incidents. Our breach notification guide covers both.

Where do vendors and processors fit?

Section 8(1) keeps you responsible for processing done on your behalf by a Data Processor, despite any agreement to the contrary. Section 8(2) allows you to engage a processor only under a valid contract, and Rule 6 asks for security safeguards to be written into that contract. Your payment gateway, messaging provider, CRM and logistics partner all expose or consume APIs that carry your customers' data. The libraries and services your developers pull in are part of the same chain. The roles guide on fiduciaries and processors explains who sits where.

For processors, we help you set out what to ask for: how they test their APIs, how they manage secrets and vulnerabilities, whether they can provide an SBOM, and how quickly they will tell you about a breach. For software you buy, asking for an SBOM at procurement is in line with CERT-In's recommendation for government, public sector and essential services organisations, and a sensible practice for others. If you run a platform, our DPDP for SaaS guide covers what your own customers are likely to ask you.

What do you get from the engagement?

We aim to leave your team running these controls, not depending on us. A typical engagement starts with discovery and authorisation testing on the APIs that carry the most sensitive data, then extends to secrets, SBOM and the pipeline. Timelines depend on how many applications and teams are in scope. For the wider programme, see our DPDP privacy engineering service, or ransomware readiness for recovery.

How to start

1. Pick a first scope. The customer-facing APIs that carry the most sensitive personal data, plus the pipeline that deploys them.
2. Gather what exists. API specifications, gateway configuration, repository access and any earlier test reports.
3. Agree authorisation. A written scope, test accounts, testing windows and an escalation contact.
4. Run the five steps. Fix the highest-risk findings as they come, and file the evidence against Rule 6.
5. Keep it running. Pipeline checks and the vulnerability register carry on after the engagement ends.

API security is one of the engineering services that sit alongside a DPDP programme. If you would like our engineers to start with your most exposed APIs, get in touch.