Security talks go faster when everyone uses the same words. This note gives you that vocabulary: what you protect (the CIA triad), what can go wrong (threats, vulnerabilities, risk), and what you do about it (controls). It ends with the one rule behind most application security: never trust input. The later notes in this category build on these terms.
What you protect: the CIA triad#
Security goals are usually stated as three properties of data and services. A fourth, authenticity, is often added next to them.
| Property | Question it answers | Example of a failure |
|---|---|---|
| Confidentiality | Can only authorized parties read the data? | A database dump leaks customer emails |
| Integrity | Is the data unchanged since it was sent or stored? | An attacker edits an amount in transit |
| Availability | Can users reach the service when they need it? | A flood of requests takes the API down |
| Authenticity | Did the data come from who it claims to? | A forged message looks like it came from your bank |
The properties pull against each other. Strong encryption and strict access checks help confidentiality, but they add steps that can hurt availability when a key service fails. Good design states which properties matter most for each piece of data.
Availability needs a concrete target to be useful. For a public cloud service, "available" usually means all day, every day. The SLO note shows how to turn that into a measurable target.
What can go wrong: the core terms#
These terms describe an attack from different angles. They are easy to mix up, so learn them as a set.
| Term | Meaning | Example |
|---|---|---|
| Vulnerability | A weakness that someone can exploit | A login form that builds SQL from raw input |
| Threat | A possible danger that could exploit a vulnerability | Someone could steal data through that form |
| Threat agent | A person or thing able to carry out the attack | An outside attacker, a malicious insider, a bot |
| Attack vector | The path the attacker uses to get in | The login form, a phishing email, an open port |
| Risk | The chance of loss or harm, and how bad it would be | High: easy to exploit and the data is sensitive |
A short way to connect them: a threat agent uses an attack vector to exploit a vulnerability. The risk is how likely that is and how much it would cost you.
Attack vectors include people, not only code. A convincing phishing email is a vector, and a staff member who clicks it is part of the attack surface (everything an attacker could target).
What you do about it: security controls#
A security control is any countermeasure that prevents, detects or responds to a threat. Controls lower risk. You rarely remove risk completely.
Controls are often grouped by when they act.
- Preventive: stop the attack. Examples: input validation, encryption, least-privilege permissions, a firewall.
- Detective: notice the attack. Examples: audit logs, alerts on failed logins, intrusion detection.
- Corrective: limit damage and recover. Examples: revoking keys, restoring from backup, patching.
No single control is enough. Defense in depth means you stack several layers, so one failure does not expose everything. For example, a web app firewall, parameterized queries and a database user with narrow rights all defend against the same SQL injection.
Hardening#
One preventive control for servers and images has its own name. Hardening means you remove everything a system does not need, so there is less to attack.
- Remove unused software and packages.
- Close ports that nothing should listen on.
- Disable unused services, guest access and shared root logins.
- Build a hardened base image once and start every server from it.
The core rule: all input is untrusted#
A web application receives input from people it does not control. Your code must treat every input as possibly hostile, and check it on the server. This one idea explains most web attacks.
It helps to see how much a user can do beyond what your UI allows.
- Change anything in the request. Parameters, cookies, headers and hidden form fields are all under the client's control.
- Skip client-side checks. JavaScript validation is a convenience for honest users. An attacker turns it off or never runs it.
- Send requests out of order. They can skip steps in a flow, repeat a step, or leave out parameters.
- Use tools other than a browser.
curl, Postman or a short script can send any request. - Automate. Attack tools and bots can send huge numbers of requests to guess passwords or find weak points.
Client-side validation improves the user experience. Server-side validation provides the security. You need the server-side check in every case.
What attackers look for#
Because they can send anything, attackers usually follow the same steps against a web app. Knowing them tells you what to protect.
- Map the app: find hidden pages and parameters, every input point, and which server technology you use.
- Bypass client-side controls: edit hidden fields, URL parameters, the
Refererheader or length limits. - Attack authentication: try weak passwords, brute-force the login, and read error messages for hints.
- Attack sessions: steal or guess the session token of another user.
- Inject code: send input that the server or browser runs as code.
Steps 4 and 5 are covered in web app attacks. For who-are-you and what-may-you-do checks, see API security considerations.
Weak spots in authentication#
Step 3 deserves a closer look, because login code is a common target. These mistakes come up again and again.
- Weak passwords are allowed.
- Unlimited login attempts, so attackers can brute-force passwords.
- Verbose failure messages, such as "no such user", which tell an attacker which usernames exist.
- A password change form that does not ask for the current password.
- An insecure "remember me" token that never expires or is easy to guess.
- Passwords stored in plain text, or hashed without a salt. See encryption, hashing and signatures for the correct way.
Key takeaways#
- The CIA triad is confidentiality, integrity and availability. Authenticity asks whether data came from its claimed source.
- A threat agent uses an attack vector to exploit a vulnerability. Risk is how likely and how costly that is.
- Controls prevent, detect or correct. Stack them in layers (defense in depth).
- Hardening removes software, ports and accounts that a server does not need.
- Treat all input as untrusted and validate it on the server. Client-side checks are not security.