Securing Applications and Data

What this unit covers

The topics below follow the published Cybersecurity course framework for Unit 5. Cybersecurity publishes no per-unit weighting, so there is no percentage to chase here.

Lessons in this unit

• Applications, Data, and Cryptography20 min · 3 objectivesExplain how access controls protect confidentiality and integrity · Distinguish encryption, hashing, and authentication · Recognize common application attack evidence
• Secure Application Design18 min · 3 objectivesExplain input handling, authorization, and safe failure · Apply the idea to evidence from a realistic technology scenario · Justify a decision using security, reliability, cost, and user impact
• Cryptography, Backups, and Data Governance18 min · 3 objectivesExplain data protection across storage, transit, use, and recovery · Apply the idea to evidence from a realistic technology scenario · Justify a decision using security, reliability, cost, and user impact

Every term in Unit 5

All 46 terms we publish for Securing Applications and Data, with definitions. Reading them through is the fastest way to find the ones you cannot define — then drill those in cram mode until you can produce them without the prompt.

SQL injection

Untrusted input interpreted as database commands, letting an attacker read, alter or destroy data. Parameterized queries prevent it; filtering for quotes does not.

Cross-site scripting (XSS)

Untrusted input rendered into a page executes as script in a victim's browser under the site's origin — enabling session theft or actions as the victim. Fixed by contextual output encoding.

3-2-1 backup rule

Three copies, on two media types, one offsite. Add: at least one offline or immutable, because ransomware encrypts reachable connected backups.

Access control model

The rule set deciding who may do what. The four examinable models are DAC, MAC, RBAC and ABAC.

Discretionary access control (DAC)

The data owner decides who gets access. Flexible, and it makes over-sharing an individual decision nobody reviews.

Mandatory access control (MAC)

The system enforces access from labels and clearances; owners cannot override it. Used where classification is legally binding.

Role-based access control (RBAC)

Permissions attach to roles, and users are assigned roles. Scales well and makes joiners, movers and leavers manageable.

Attribute-based access control (ABAC)

Decisions from attributes of user, resource, action and context — including time and location. The most granular and the most complex to reason about.

Privilege creep

Permissions accumulating as someone changes roles without the old ones being removed. The standard finding of an access review.

Access review (recertification)

Periodically confirming that each account still needs what it has. The control that catches privilege creep and orphaned accounts.

Account lifecycle

Provisioning on hire, adjustment on role change, and prompt disablement on departure. The departure step is the one organizations most often get wrong.

Service account

A non-human account used by an application. Often over-privileged, rarely rotated and easy to forget — a common target.

Encryption

Transforming data so only holders of the key can read it. Protects confidentiality, and by itself proves nothing about integrity or identity.

Symmetric encryption

One key encrypts and decrypts — AES is the standard. Fast, and it requires a secure way to share the key first.

Asymmetric encryption

A public key encrypts and a mathematically related private key decrypts — RSA and elliptic curve. Slower, and it solves key exchange.

Why both are used together

Asymmetric cryptography securely exchanges a symmetric session key; the symmetric key then encrypts the bulk of the data quickly. This is what a TLS handshake does.

Hashing

A one-way function producing a fixed-length digest. Not encryption — there is no key and nothing to reverse — and its purpose is verifying integrity.

Properties of a good hash

Deterministic, fast to compute, infeasible to reverse, and collision-resistant. SHA-256 is the current standard; MD5 and SHA-1 are broken for security use.

Salting

Adding a unique random value to each password before hashing, so identical passwords produce different digests and precomputed tables are useless.

Rainbow table

A precomputed lookup from hashes back to inputs. Defeated entirely by salting, which is why unsalted password storage is a serious finding.

Key stretching

Deliberately slow hashing — bcrypt, scrypt, PBKDF2 — so that guessing passwords in bulk becomes expensive. Speed is a flaw in a password hash.

Digital signature

A hash of a message encrypted with the sender's private key. Provides integrity, authentication and non-repudiation at once — confidentiality is not among them.

Public key infrastructure (PKI)

The system of certificate authorities, certificates and revocation that lets strangers trust a public key belongs to who it claims.

Digital certificate

A signed statement binding a public key to an identity. Trust comes from the issuing authority, which is why a self-signed certificate warns.

Certificate authority

An organization that verifies identity and issues certificates. Compromising one undermines every certificate it signed.

Certificate revocation

Invalidating a certificate before expiry through a revocation list or OCSP. Necessary because a leaked private key cannot be un-leaked.

TLS

The protocol securing traffic in transit — the S in HTTPS. Provides encryption, integrity and server authentication.

Data at rest, in transit, in use

Three states needing different controls: disk and database encryption, TLS, and memory protection respectively. Data in use is the hardest to protect.

End-to-end encryption

Only the communicating endpoints can read the content — the service carrying it cannot. Distinct from encrypting only the link to the server.

Cross-site request forgery (CSRF)

Tricking an authenticated browser into submitting an unintended request. Anti-CSRF tokens and SameSite cookies prevent it.

Buffer overflow

Writing past the end of allocated memory to corrupt adjacent data or redirect execution. Bounds checking and memory-safe languages prevent it.

Directory traversal

Manipulating a file path to reach files outside the intended directory. Canonicalizing and validating paths prevents it.

Input validation

Checking untrusted input against what is expected before use — preferably by allowlist. The single control behind most application-attack defenses.

Why client-side validation is not security

Anything enforced in the browser can be bypassed by sending the request directly. Client-side checks are a usability feature; the server must re-check everything.

Race condition

Behavior depending on the timing of concurrent operations, exploitable when a value is checked and then used with a gap in between.

Insecure deserialization

Reconstructing objects from untrusted data, which can execute attacker-chosen code. Avoid deserializing untrusted input at all.

Hardcoded secrets

Credentials or keys committed into source code, where they reach every copy of the repository and every backup. Secrets belong in a managed store.

Secure software development lifecycle

Building security into requirements, design, coding, testing and deployment rather than testing for it at the end, when fixes are most expensive.

Code review and static analysis

Human review and automated scanning of source for flaws before release. Finds classes of bug that runtime testing misses.

Data classification

Labeling data by sensitivity — public, internal, confidential, restricted — so protection is proportionate. Controls cannot be sensible until this exists.

Data loss prevention (DLP)

Tooling that detects and blocks sensitive data leaving by email, upload or removable media. Depends entirely on classification being accurate.

Personally identifiable information

Data identifying a specific person, including combinations that identify together. Attracts legal obligations that ordinary business data does not.

Data minimization

Collecting and keeping only what is needed. Data you never held cannot be breached, which makes retention limits a security control rather than a filing policy.

Anonymization vs pseudonymization

Anonymized data cannot be traced back to a person; pseudonymized data can, given the key. The second is still personal data in law.

Why backups must be tested and offline

An untested backup is a hope, and a backup reachable from the network is encrypted along with everything else by ransomware.

Incident response phases

Preparation, identification, containment, eradication, recovery, lessons learned. The last one is what stops the same incident happening twice, and is the one most often skipped.

What examiners penalize here

• For a scenario about **input handling, authorization, and safe failure**, identify the decisive evidence before naming a response. A defensible conclusion here is: This is an authorization flaw; hiding or randomizing the URL is not a substitute for server-side access checks.
• For a scenario about **data protection across storage, transit, use, and recovery**, identify the decisive evidence before naming a response. A defensible conclusion here is: Separate and restrict key management; encryption without protected keys does not meaningfully reduce disclosure risk.

Practice Cybersecurity

Our practice bank is drawn from across the whole course rather than filtered to one unit, which is closer to how the exam asks anyway — it will not tell you which unit a question is testing.

Questions about this unit

All 5 units of AP Cybersecurity

1. Unit 1 · Introduction to Security
2. Unit 2 · Securing Physical Spaces
3. Unit 3 · Securing Networks
4. Unit 4 · Securing Devices
5. Unit 5 · Securing Applications and Data