Your API Is Not Just a Feature - It Is Your Trust Boundary
Every API call is a trust decision. When a client sends a request to your API and receives a response, both sides are implicitly trusting that the data exchanged is accurate, complete, and unmodified in transit.
Most API security focuses on authentication (who is making this request?), authorisation (are they allowed to make it?), and rate limiting (how many requests can they make?). These are necessary. But they miss the data integrity layer entirely.
Authentication proves identity. It does not prove that the data associated with that identity has not been tampered with upstream in your pipeline, corrupted in transit, or modified by a compromised internal service. In complex distributed systems and microservice architectures, data can be modified at dozens of points before it reaches an API endpoint - and the API has no way to know.
In 2026, with NIS2's supply chain security requirements, DORA's ICT third-party risk management, and the EU AI Act's data governance obligations, API-level data integrity is moving from a best practice to a compliance requirement.
The Four API Data Integrity Risks
The data integrity risks at the API layer fall into four categories:
Man-in-the-middle modification. Even over HTTPS, TLS termination at load balancers and proxies means data is decrypted and re-encrypted at multiple points. An attacker who controls a point in that chain can modify data without the client or server knowing. TLS guarantees transport security, not end-to-end data integrity.
Upstream pipeline corruption. If your API returns data from a database, cache, or microservice, and that data was modified somewhere in the pipeline - by a compromised internal service, a storage corruption event, or a deliberate attack - your API faithfully returns the corrupted data. The API itself is secure. The data is not.
