CIA Triad in Backend Services

Welcome to the first lesson of your cybersecurity course. We will begin with a framework that appears throughout security engineering, Security+ preparation, architecture reviews, and incident reports: the CIA triad.

This first module establishes the language and habits needed to assess systems before testing or hardening them. Today, you will apply confidentiality, integrity, and availability to a backend service rather than treating them as abstract definitions. By the end, you should be able to explain what each property protects, identify how it can fail, and propose sensible safeguards for a realistic service.

---

The CIA triad: three properties, one service

The CIA triad describes three security objectives:

• Confidentiality: prevent unauthorized disclosure of information.
• Integrity: prevent unauthorized or undetected alteration of information; preserve its trustworthiness and source.
• Availability: ensure authorized users can access needed information and services when required.

The triangle is useful because a backend service rarely has just one security objective. An online service needs to protect customer data from exposure, ensure orders are accurate and authentic, and remain usable during failures or attacks. A control that improves one property can also affect another.

For example, requiring authentication before viewing account data supports confidentiality. If that authentication provider is unavailable, however, users may be unable to access the service, creating an availability problem. Security design is therefore not merely “adding protections”; it is choosing protections that fit the service’s actual needs and failure modes.

---

A backend-service scenario

Consider a fictional internet-facing service, ParcelTrack, used by merchants to create shipments and by customers to view delivery status. Its simplified flow is:

The system handles several valuable things:

• Customer names, delivery addresses, phone numbers, and shipment histories
• Merchant API credentials and internal service secrets
• Shipment state, such as created, label purchased, in transit, and delivered
• Operational logs, backups, source code, and the service’s ability to respond to requests

CIA applies to data at rest (stored in databases, backups, logs, and configuration files), data in transit (moving between clients and services), and data in use (being processed in memory or displayed in an administrative interface).

A useful way to analyze a security event is to ask:

1. Was something revealed to an unauthorized party? This is primarily confidentiality.
2. Was something changed, forged, deleted, or made untrustworthy? This is primarily integrity.
3. Could legitimate users still obtain the service they needed? This is primarily availability.

One event can harm more than one part of the triad. An attacker who steals a privileged merchant credential might first compromise confidentiality by reading shipment records, then integrity by changing delivery addresses, and finally availability by deleting production data.

---

Confidentiality: who is allowed to know?

Confidentiality is not synonymous with “having a password.” It is the broader outcome that only authorized entities can access particular information. Those entities may be human users, an API client, an internal service, or an administrator.

For ParcelTrack, confidentiality means:

• A customer can view only their own shipments.
• Merchant A cannot retrieve Merchant B’s customer addresses.
• A support employee sees only the records necessary for their role.
• An outside observer cannot read addresses or authentication tokens travelling across a network.
• Database backups and application logs do not disclose credentials or sensitive customer information to unauthorized people.

There are two major families of confidentiality controls:

Control family	What it addresses	ParcelTrack example
Access control	Whether an entity may access a resource or perform an action	Verify a merchant’s identity and authorize access only to that merchant’s shipment records
Encryption	Whether intercepted or stolen data can be read without a key	Use TLS for client-to-API traffic and encrypt sensitive database backups

Access control has two distinct decisions:

• Authentication: “Who are you?”
• Authorization: “Given who you are, may you perform this specific action on this specific resource?”

A valid login alone does not make a request safe. Suppose a logged-in customer requests:

GET /api/shipments/84721

The API must check not only that the requester is authenticated, but that shipment 84721 belongs to that requester or that the requester has an appropriate support or merchant role. This resource-level check is a major backend responsibility.

Encryption also operates in different places. TLS protects the connection between a client and service, preventing a network observer from reading its contents and providing further protections that will be explored in the cryptography module. But TLS alone does not protect a database backup copied to an exposed storage location, nor does it prevent an authorized but overprivileged user from viewing records they should not access.

Confidentiality failure example: a developer enables detailed request logging in production, and the logs record Authorization headers containing bearer tokens. An employee with broad log access, or an attacker who obtains log access, can reuse those tokens. The immediate problem is unauthorized disclosure of credentials. The downstream impact could expand into integrity and availability issues if the tokens are used to alter or delete data.

---

Integrity: can we trust the data and its source?

Integrity means that information remains accurate, complete, and changed only by legitimate, authorized actions. It also includes source integrity: confidence that the data came from, or was changed by, the claimed legitimate source.

For ParcelTrack, integrity means that:

• A shipping address is not changed by an unauthorized party.
• The service does not accept a shipment status forged to look as though it came from a carrier.
• A merchant cannot alter another merchant’s orders.
• A database fault or faulty deployment does not silently corrupt shipment records.
• Security logs remain trustworthy enough to support investigation.

A common misconception is that encryption alone guarantees integrity. Encryption principally makes data unreadable to parties without the appropriate key. Modern TLS provides integrity protection for traffic in transit as well, but protecting stored business records needs additional mechanisms: authorization checks, database constraints, transaction handling, audit trails, controlled deployment, backups, and validation.

Cryptographic integrity mechanisms serve different purposes:

• A hash produces a fixed-size digest of data. If a known-good hash is trusted, comparing hashes can reveal accidental or deliberate modification.
• A keyed hash or message authentication code lets parties sharing a secret verify both integrity and knowledge of that secret.
• A digital signature can verify that data has not been modified and associate it with the holder of a signing key.

The cryptography module will develop these mechanisms carefully. For now, the essential operational point is: detecting that a record was changed is valuable, but preventing unauthorized changes is better. A secure service normally uses both preventive and detective measures.

Consider this request:

PATCH /api/shipments/84721
{"delivery_address": "New address"}

Maintaining integrity requires more than validating that delivery_address has the right syntax. The backend should also verify that:

1. the requester is authenticated;
2. the requester is authorized to change this particular shipment;
3. the requested state transition is allowed;
4. the change is recorded in an audit trail with relevant context;
5. the database accepts only data that satisfies its constraints.

Input validation protects data quality, while authorization protects against unauthorized action. Both support integrity, but they address different failure modes.

Integrity failure example: an attacker gains access to a support account and changes a high-value shipment’s address. The address remains syntactically valid, so basic input validation does nothing. The actual integrity failure is that an unauthorized or insufficiently authorized actor was able to make a meaningful business change.

---

Availability: can authorized users use the service?

Availability is the property that authorized users can access needed systems and information within the required service window. It is not simply “the server is powered on.” A service may be technically running while users cannot log in, requests time out, database connections are exhausted, or a downstream dependency causes every request to fail.

For ParcelTrack, availability might require that:

• Customers can check delivery status during normal service hours.
• Merchants can create labels within a defined response-time target.
• Operations staff can restore service and data after a failure.
• One failed instance, disk, or dependency does not automatically take down the whole service.

Availability failures can be malicious, accidental, or environmental:

Cause	Example	Availability effect
Resource exhaustion	Attackers send expensive requests faster than the API can process them	Legitimate requests queue or time out
Software defect	A deployment leaks memory or creates excessive database connections	Instances crash or become unresponsive
Infrastructure failure	A database node or availability zone fails	The service loses an essential dependency
Misconfiguration	A firewall rule blocks the carrier API or expires a certificate	A critical workflow becomes unusable
Dependency outage	The authentication or payment provider fails	Users cannot authenticate or complete actions

A denial-of-service attack is one direct threat to availability. It may be a volume of traffic, a flood of incomplete connections, or a smaller number of computationally expensive requests. But a backend engineer should also recognize self-inflicted availability failures: unbounded queries, unlimited upload sizes, missing timeouts, synchronous calls to a slow dependency, and a single database instance with no tested recovery plan.

Appropriate availability controls work in layers:

• Bound work per request: request-size limits, input validation, query limits, timeouts, concurrency limits, and rate limiting.
• Prevent one component from exhausting the host: CPU, memory, file-descriptor, process, and connection limits.
• Remove single points of failure: redundant instances, load balancing, replicated data where justified, and health checks.
• Recover deliberately: tested backups, documented recovery procedures, and deployment rollback.
• Observe the service: metrics, logs, alerts, capacity monitoring, and dependency checks.
• Maintain the platform: patching and configuration management reduce vulnerabilities and stability failures.

Availability does not mean allowing unlimited access. For example, rate limiting may reject some excessive requests in order to preserve capacity for legitimate customers. That is an availability control.

---

Applying CIA as an engineering checklist

When reviewing a feature, architecture change, or incident, use the triad as a set of concrete questions rather than a slogan.

For a new endpoint that lets a merchant download a monthly shipment report:

Confidentiality

• Does the endpoint use TLS?
• Are the merchant identity and tenant relationship checked on every request?
• Could the report, token, or personal data appear in logs, error messages, caches, or backups?
• Is the report protected appropriately while stored?

Integrity

• Can someone request or generate a report for another merchant by manipulating an identifier?
• Is the report generated from trustworthy, current records?
• Are the report-generation event and download meaningfully audited?
• Can an attacker alter the report while it is transferred or stored without detection?

Availability

• Can an unusually large report consume excessive CPU, memory, database capacity, or storage?
• Are there timeouts, size limits, queues, or rate limits?
• What happens if the reporting database or external dependency is slow?
• Can the service degrade gracefully without preventing core shipment tracking?

The three properties should be prioritized according to the system’s context. A public status page may emphasize availability. A payment instruction may place especially high weight on integrity. A healthcare or identity service often has exceptionally high confidentiality requirements. Yet none of the three can be ignored: highly available but publicly exposed customer data is not secure; encrypted but unreliable data is not useful; accurate data that users cannot reach fails the service’s mission.

---

Key takeaways

• The CIA triad frames security as confidentiality, integrity, and availability of information and the systems that handle it.
• Confidentiality prevents unauthorized disclosure through access control, careful data handling, and encryption.
• Integrity preserves accurate, authorized, and trustworthy data. It depends on authorization, validation, constraints, auditability, and—in appropriate cases—cryptographic verification.
• Availability means authorized users can use the required service when needed. It requires both resilience against attacks and operational engineering against ordinary failures.
• A backend security review should consider data in transit, at rest, and in use, and should ask how each CIA property might fail.

Next, you will build on this vocabulary by distinguishing assets, threats, vulnerabilities, exploits, risks, and controls. That distinction turns the CIA objectives into a structured way to describe what can go wrong and what should be done about it.