The CIA Triad in Web Apps
The CIA triad — Confidentiality, Integrity, Availability — is the classic model security professionals use to reason about what a control is actually protecting. Confidentiality means only authorized parties can read data, whether that's a user's own profile or an internal admin dashboard; integrity means data can't be modified by unauthorized parties or corrupted without detection, whether it's an order total or an audit log; availability means the system keeps responding to legitimate requests even under load or attack. In a real web application, these three properties trade off against each other constantly — adding heavier encryption can slow down response times (affecting availability), and aggressive rate limiting meant to protect availability can accidentally lock out legitimate users during a traffic spike.
Cricket analogy: A scorecard's confidentiality means only the official scorers can access the raw match data before it's published, its integrity means the final score can't be silently altered after the match, and its availability means fans can actually check the live score during the game without the app crashing.
When Each Pillar Fails
A confidentiality failure typically looks like an Insecure Direct Object Reference (IDOR), where changing an ID in a request exposes another user's private data, or a misconfigured cloud storage bucket left publicly readable. An integrity failure often shows up as a race condition — for example, two simultaneous requests to redeem the same discount coupon both succeeding because the check-then-use logic wasn't atomic — or as a compromised software update mechanism that lets an attacker inject malicious code into a trusted deployment pipeline. Availability failures range from a straightforward Distributed Denial of Service (DDoS) flood to a subtler application-layer attack, such as sending computationally expensive search queries that exhaust database resources far faster than the request volume alone would suggest.
Cricket analogy: A confidentiality failure is like a scorer's app letting any fan swap the match ID in the URL and pull up the opposing dressing room's private team-selection notes meant only for coaching staff.
Designing With All Three in Mind
Mature applications don't treat CIA as three separate checklists; they design controls that address them together. Encrypting data at rest with a well-managed key (confidentiality) combined with database-level checksums or audit logging (integrity) and a well-provisioned, auto-scaling infrastructure with circuit breakers (availability) work in concert, and a good architecture review explicitly asks 'what happens to confidentiality, integrity, and availability if this component fails?' for every new feature. Trade-offs are unavoidable: a highly available public API that skips per-request authorization checks for speed sacrifices confidentiality, while an overly strict rate limiter meant to protect availability during an attack can itself become a denial-of-service vector against legitimate users if tuned too aggressively.
Cricket analogy: A well-run cricket board doesn't handle player medical records, match footage rights, and stadium capacity as unrelated problems — a data breach review asks how leaked medical data (confidentiality), tampered footage (integrity), and a crashed ticketing app (availability) would each play out for every new system.
# Idempotency key prevents a retried request from breaking integrity
@app.route('/transfer', methods=['POST'])
def transfer_funds():
idempotency_key = request.headers.get('Idempotency-Key')
existing = db.find_transaction(idempotency_key)
if existing:
return jsonify(existing.result), 200 # safe to return cached result
result = process_transfer(request.json)
db.save_transaction(idempotency_key, result)
return jsonify(result), 201Some practitioners extend CIA with two more properties: Authenticity (proving data or a message really came from who it claims) and Non-repudiation (preventing someone from denying an action they took, often via signed audit logs). These build on integrity but are worth naming separately in security design discussions.
Don't assume HTTPS alone satisfies confidentiality. TLS protects data in transit between the client and server, but data sitting unencrypted in a database, log file, or backup is still exposed to anyone with access to that storage.
- Confidentiality, Integrity, and Availability form the classic CIA triad used to reason about security controls.
- Confidentiality failures often appear as IDOR bugs or misconfigured public storage buckets.
- Integrity failures often appear as race conditions or compromised update/deployment pipelines.
- Availability failures range from DDoS floods to subtler application-layer resource exhaustion attacks.
- The three properties trade off against each other, so controls must be designed together, not in isolation.
- HTTPS alone only protects data in transit; data at rest needs its own encryption for real confidentiality.
- Authenticity and non-repudiation are sometimes added as extensions to the classic CIA triad.
Practice what you learned
1. In the CIA triad, what does 'integrity' specifically protect against?
2. Which scenario is a classic example of a confidentiality failure?
3. Why is HTTPS alone insufficient to guarantee data confidentiality?
4. What does the idempotency key pattern shown in the lesson's code example protect?
5. What is an example of an availability failure beyond a simple traffic-flood DDoS attack?
Was this page helpful?
You May Also Like
What Is Web Application Security?
An introduction to why web applications are attacked, what an attack surface is, and the core disciplines that keep applications and their data safe.
The OWASP Top 10 Overview
A tour of the OWASP Top 10, the industry-standard list of the most critical web application security risks and why it matters to every developer.
Threat Modeling Basics
A practical introduction to threat modeling, including the STRIDE framework, data flow diagrams, and how to run a lightweight threat modeling session.
Secure SDLC Overview
How security practices integrate into every phase of the software development lifecycle, from requirements gathering through deployment and maintenance.