Data integrity ensures the message has not been altered in transit, usually through digital signatures such as JWT or HMAC. Data confidentiality protects the contents from being read by unauthorized parties, typically through encryption, masking, tokenization, or TLS. One proves the message is unchanged, the other keeps its contents private.
How integrity and confidentiality solve different API security problems
Data integrity and data confidentiality protect different parts of an API exchange, even though they are often implemented together. Integrity is about trust in the content itself: the payload, headers, or claims have not been changed without detection. Confidentiality is about exposure: the content may exist in transit or at rest, but unauthorized parties cannot read it.
That distinction matters because an API can be confidential but not integrity-protected, or integrity-protected but still readable by anyone who intercepts it. For example, TLS can keep traffic private on the wire, while a message signature or MAC can prove the message was not altered before it reached the receiver.
In practice, integrity is the control that answers, “Can I trust this API message to mean what the sender intended?” Confidentiality answers, “Can an attacker or unintended recipient understand the message?” They address different failure modes, so one does not replace the other.
What each control is defending in the API request path
Integrity protects against tampering, replay-adjacent manipulation, and unauthorized field changes that can alter business meaning. If an API request says “transfer 100” and an attacker changes it to “transfer 10,000,” confidentiality alone does nothing to stop that modification. A signature, HMAC, or similarly verifiable mechanism is what lets the server detect the change.
Confidentiality protects against disclosure of tokens, personal data, account details, credentials, and other sensitive fields that should not be visible to intermediaries or observers. Encryption in transit, field-level encryption, masking, and tokenization all reduce the chance that data exposure becomes a breach event. OWASP API Security Top 10 is a useful reference point because API abuse frequently combines weak transport protection with broader authorization and data exposure failures.
These controls also operate at different layers. Confidentiality is often transport-layer or payload-layer protection. Integrity may be transport-layer, message-layer, or object-layer depending on whether the consumer must verify the exact payload after it passes through gateways, queues, or service intermediaries.
Why the difference matters when you design or review APIs
The practical question is not which control sounds stronger, but which one matches the failure you are trying to prevent. If the risk is eavesdropping, you need confidentiality. If the risk is undetected alteration, you need integrity. In many APIs, especially those crossing proxies, brokers, and third-party integrations, both are required because the message can be safe to read but still unsafe to trust.
For message integrity, the important verification step is that the receiver can independently detect tampering after transit. For confidentiality, the important verification step is that sensitive fields are protected wherever the message may be observed, not only on the first network hop. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates access, transmission protection, and system integrity concerns into distinct control expectations.
When APIs carry tokens, claims, or signed business instructions, integrity often becomes the first control to validate because a readable message is still safe only if its semantics cannot be changed. When APIs carry personal, financial, or credential-like data, confidentiality becomes the first control to validate because even correctly formed traffic can still leak sensitive content.
Ultimate Guide to NHI is especially relevant where APIs are driven by service accounts, keys, or tokens, because those identities often sit behind the confidentiality and integrity controls being discussed. T-Mobile breach also illustrates how API exposure and access control failures can quickly turn data protection gaps into broad compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | V4 — API and Web Service | API messages need transport and object protection to prevent tampering and disclosure. |
| Recommendation — Apply V4 checks to protect API payloads against alteration and unintended exposure. | ||
| NIST SP 800-53 Rev 5 | SC-13 — Cryptographic Protection | Cryptography underpins confidentiality and integrity for API data in transit. |
| SI-7 — Software, Firmware, and Information Integrity | API integrity depends on detecting unauthorized message or content changes. | |
| AC-4 — Information Flow Enforcement | API confidentiality often depends on controlling who can receive or inspect data flows. | |
| Recommendation — Use SC-13 to protect API data with encryption and integrity mechanisms. Use SI-7 to verify API messages and detect unauthorized alteration. Use AC-4 to limit where API data may flow and who may inspect it. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Cryptography is central to protecting API confidentiality and message integrity. |
| Recommendation — Apply A.8.24 to select and manage encryption and integrity protections for API traffic. | ||
Practitioner Guidance
What to verify: Validate integrity at the point where the receiver makes a decision, not just at transport entry. If a gateway, queue, or downstream service can change the message, the signature or MAC must still be checked after those hops.
Trade-off: Strong confidentiality controls can add operational friction through key handling, certificate management, and payload handling complexity, while strong integrity controls can require more careful canonicalization and verification logic. Do not assume one control compensates for the other.
What good looks like: Sensitive API data is encrypted in transit and, where needed, in fields or objects, while business-critical messages are signed or otherwise verifiable end to end. The receiver can prove both who sent the message and that the message was not altered.
Practitioner takeaway: Treat confidentiality as protection from being seen and integrity as protection from being changed; in API security, you usually need both because exposure and tampering fail in different ways.
Related resources from NHI Mgmt Group
- What is the difference between data transfer security and data confidentiality for PII?
- What is the difference between a compliant backup plan and basic data storage?
- What is the difference between a traditional data governance tool and an enterprise data intelligence platform?
- What is the difference between role-based access and API key governance for NHI security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
