The Compliance Blind Spot: Public APIs That Expose Personal Data

Most large organizations in the Kingdom now operate two mature control planes. The data team runs a data catalog: tables are inventoried, columns carry classification labels, owners are named, access policies are reviewed. The platform team runs an API gateway: traffic is authenticated, rate-limited, versioned, and logged.

Each plane works well. Neither talks to the other. And in the seam between them sits one of the least visible compliance failures in modern architecture: a column classified as Restricted in the catalog, flowing out through a public API endpoint that nobody on the governance side knows exists.

Two Disciplines That Never Meet

Data governance and API management grew up in separate worlds, and it shows in the questions each answers.

• The catalog answers: what data do we hold, how sensitive is it, who owns it, who may access it?
• The gateway answers: which endpoints are published, who is calling them, are they authenticated, throttled, available?

The question neither answers: which of our public endpoints return personal data — and does each one have a legal basis to do so?

This gap is structural, not negligent. The catalog's unit of governance is the table and the column. The gateway's unit of management is the route and the consumer. Between them sits the service layer, where an engineer writes a query, maps the result to a JSON object, and publishes a route. At that exact moment the classification label silently falls off: the data keeps moving, the metadata stays behind.

Anatomy of the Blind Spot

Trace a single value through a typical stack:

1. A national_id column sits in the CRM database. The data office has classified it as Restricted; the catalog shows the label, the owner, and the access policy. So far, fully governed.
2. A backend service queries the column to assemble a customer-profile object. From this moment on, the classification exists only in the catalog — the service code carries no trace of it.
3. The object is serialized into the JSON response of GET /v1/customers/{id}.
4. The endpoint is registered on the gateway as internal. Six months later, a partner-integration project flips its visibility to public. The change request mentions a “customer profile endpoint” — not the eleven personal-data fields inside the payload.
5. Both dashboards stay green. The catalog still shows a Restricted column under tight access control. The gateway shows healthy, authenticated traffic. Personal data is leaving through the front door, and every monitoring screen says all is well.

No single step is reckless; each is locally reasonable — which is exactly why the pattern is so common. Now multiply it by every API version that was never retired, every deprecated endpoint still quietly serving traffic, and every shadow API a team published without telling the platform group.

Why DLP and WAF Don't Catch It

The instinctive objection from a security team: “we have a WAF and a DLP suite.” Both are valuable; neither was built for this problem.

• The WAF inspects inbound traffic for attack signatures — injection, scraping, malformed requests. An authenticated client receiving a well-formed 200 response is, from the WAF's perspective, the system working as designed. There is no attack to detect, because exposing the field is the design.
• DLP pattern-matches egress channels such as email and file transfers. API responses are structured, TLS-encrypted, high-volume, and legitimate-looking. A pattern matcher can flag a ten-digit string, but it cannot judge whether this field is permitted in this endpoint for this consumer. It knows what personal data looks like; it does not know what the data is, who owns it, or what its classification says. The result is noise without judgment.
• Gateway analytics know the route, the consumer, status codes, and latency — and nothing about what the payload means.
• The catalog knows precisely what the data is — and nothing about the endpoints it flows through.

The blind spot is not a missing tool. It is a missing connection between tools that are each doing their own job correctly.

What API Governance Actually Means

Closing the seam takes four capabilities, in sequence:

1. Discovery from the gateways

Just as a catalog crawls databases for tables, it should harvest the API inventory from gateways and OpenAPI specifications: every endpoint, version, environment, visibility level (internal, partner, public), and authentication scheme. This step alone surfaces shadow APIs and zombie versions — usually the first uncomfortable findings.

2. Endpoint-to-table lineage

Lineage usually stops at the warehouse or the dashboard. API governance extends it to the serving layer: endpoint → service → query → table → column. This is the load-bearing capability; without it, everything else is guesswork.

3. Classification inheritance

Once lineage exists, classification can travel with the data: if a response field traces back to a Restricted column, the endpoint inherits Restricted automatically. Reclassify a column once, and every endpoint exposing it updates — no manual re-tagging campaign.

4. Exposure scoring

Not every finding deserves a war room. Combine the sensitivity of inherited classifications with visibility (public outranks partner outranks internal), authentication strength, and traffic volume to produce a ranked exposure score. A public endpoint returning national IDs behind a static API key is a different conversation from an internal endpoint returning hashed emails behind mTLS.

The PDPL and NDMO Data Sharing Angle

For Saudi organizations, this is not a theoretical hygiene exercise.

The Personal Data Protection Law (PDPL) has been fully enforced since September 2024, with SDAIA as the enforcement authority. The law governs the disclosure of personal data — and a JSON response is a disclosure in exactly the same sense as a file handed to a third party. Disclosing personal data without a legal basis carries penalties of up to SAR 5 million, doubling to SAR 10 million for repeat violations. The uncomfortable corollary: you cannot demonstrate that every disclosure is lawful if you cannot enumerate the endpoints performing disclosures.

The NDMO framework — 15 domains, 77 controls, 191 specifications — treats both Data Sharing and Data Classification as governed domains. The sharing controls expect an organization to know what data it shares externally, with whom, and under what agreement; the classification controls expect labels to be applied and enforced wherever data resides or moves. A public API is data sharing at machine speed. An endpoint whose payload classification is unknown fails both expectations at once — and an assessor will eventually ask the question your dashboards cannot answer.

Where to Start

A pragmatic sequence for the first quarter:

• Export the inventory. Pull every published route from your gateways and API specs. Count the public ones — most teams are surprised by the number alone.
• Trace the top ten. Take the ten highest-traffic public endpoints and manually map each response field to its source column and classification. Expect at least one finding.
• Gate publication. No endpoint changes visibility to public without a recorded classification of its full response payload. Make this a change-management rule, not a guideline.
• Connect the DMO. When the data office reclassifies a column, the owners of every endpoint exposing it should be notified. That link probably does not exist in your organization today.
• Automate before it decays. Manual mappings rot within weeks of the next release. Lineage-based classification inheritance is the only version of this control that survives a real release cycle.

The principle to internalize: govern the data and the channels it leaves through as one system, not two.

Goava was built around exactly this connection — its API governance capability discovers endpoints from your gateways, links them to cataloged tables through lineage, and scores exposure against PDPL and NDMO obligations, so the seam between your two control planes is finally visible.