Keentune

Security curriculum

24 chapters
·
216 concepts
·
free
Everything the adaptive question bank can teach and test in Security, from foundations through advanced practice. Work through it in order, or start practising and let the questions find your level.
New here? Read the Security guide
A free 18-minute primer — the mental model, the mistakes beginners make, and what to practise first.
A. Security principles and the trust model
•
confidentiality, integrity and availability; most controls trade one against another
•
grant the minimum rights, to the fewest actors, for the shortest time
•
layered independent controls, so a single failure is not a breach
•
an error path must deny; an exception that skips the check is an allow
•
the shipped configuration is the one most deployments will keep forever
•
every access is authorized, not just the first one in a session
•
hiding an endpoint delays discovery; it never authorizes access
•
the point where data changes trust level is where validation must happen
•
network location grants nothing; every request is authenticated and authorized
B. Threat modeling and risk
•
spoofing, tampering, repudiation, information disclosure, denial of service, elevation
•
model processes, stores, flows and boundaries before enumerating threats
•
the count of reachable entry points, not the count of known bugs
•
a critical weakness in unreachable code is not a critical risk
•
the feature working exactly as designed, turned against the business
•
design for containment after compromise, not only for prevention
•
accepted risk is a documented decision with an owner, not an absence of risk
•
a flaw in the design cannot be patched by fixing a line of code
C. Vulnerability taxonomy and the OWASP Top 10
•
the Top 10 ranks awareness categories; ASVS is the testable standard
•
the failure is missing or misapplied protection, rarely a broken cipher
•
the 2025 edition promoted software supply chain to its own category
•
one concrete bug maps to several categories, so learn the cause not the number
•
CWE names a weakness class; CVE identifies one instance in one product version
•
the base score ignores your exposure and compensating controls
•
a weakness, a working attack against it, and the actor who would run it
•
L1 opportunistic, L2 the standard target for most applications, L3 high assurance
D. API security
•
broken object-level authorization: ownership is re-checked per object, not once per route
•
broken function-level authorization: an admin action reachable by guessing the method or path
•
binding a request body straight onto a model lets a caller set fields like isAdmin
•
returning the whole record and filtering in the client still leaks it
•
no rate, size or cost limit turns your own API into the denial-of-service weapon
•
automating a legitimate flow at scale (bulk signup, scalping) is an API risk
•
the forgotten v1 host and the staging deployment are the ones that get hit
•
a response from a third-party API is untrusted input and needs the same validation
•
the gateway validates the token; the service still authorizes the object
E. Access control and authorization
•
who you are versus what you may do; a valid token is not a permission
•
hiding a button is user experience, not access control
•
a direct object reference the server accepts without an ownership check
•
a UUID raises the guessing cost; it does not check ownership
•
reaching another user's data at the same privilege level
•
reaching a function reserved for a higher role
•
anything not explicitly permitted is refused, including routes added later
•
coarse roles versus attribute and context rules, and where each stops scaling
•
a 403 confirms the object exists; a 404 keeps even that secret
F. Injection
•
injection is data crossing into the instruction position of an interpreter
•
binding sends values out of band, so they can never be parsed as SQL
•
escaping depends on charset, context and dialect; binding does not
•
no output, so the attacker reads the database through boolean or timing differences
•
input stored safely on write and injected when a later query reads it back
•
an operator object such as a $ne document injected where a scalar was expected
•
pass an argument vector; a shell string re-parses metacharacters as syntax
•
dot-dot segments and their encodings; canonicalize first, then check the prefix
•
user input rendered as a template is server-side code execution, not merely XSS
•
an external entity in XML reads local files or reaches internal hosts; disable DTD processing
•
a byte stream that instantiates types becomes a gadget chain to code execution
G. Cross-site scripting and output encoding
•
untrusted data rendered where the browser parses it as markup or code
•
echoed back from one request versus persisted and served to every later viewer
•
the sink is in client JavaScript, so the payload may never reach the server at all
•
HTML body, attribute, URL, JavaScript and CSS each need a different escape
•
innerHTML, document.write, eval and a javascript: URL all re-enter a parser
•
the same string is harmless in one output context and hostile in another
•
sanitize with a real HTML parser; a regex blocklist is always bypassable
•
the browser rewrites markup after sanitization and resurrects a neutralized payload
H. The browser security model, CORS and response headers
•
scheme, host and port must all match for scripted cross-document access
•
CORS tells the browser it may expose a response; it is not server-side access control
•
echoing whatever Origin arrives re-implements a wildcard and defeats CORS
•
non-simple methods, headers or content types trigger an OPTIONS check first
•
a policy constrains which sources may run, capping the impact of an injection
•
per-response nonces beat host allowlists, which are routinely bypassed
•
allowing inline script restores exactly what the policy was there to block
•
the real UI framed under a decoy; deny framing with frame-ancestors
•
the browser refuses plaintext for the host after the first successful visit
•
a hash pins the exact third-party file the page is allowed to execute
•
a full URL in the Referer header leaks tokens and internal paths to third parties
I. CSRF, SSRF and the confused deputy
•
a trusted component is tricked into using its authority on the attacker's behalf
•
the browser attaches ambient credentials to a cross-site request the user never intended
•
an unguessable per-session value the attacker's page can neither read nor predict
•
Lax blocks most cross-site sends; Strict also breaks legitimate inbound links
•
the request is still delivered; only the response is withheld from script
•
the server fetches an attacker-chosen URL from a position inside the network
•
the link-local instance metadata endpoint hands out cloud credentials
•
decimal, octal, IPv6 and redirect encodings defeat every deny list
•
an unvalidated redirect target launders phishing and leaks tokens left in the URL
J. Authentication, sessions and cookies
•
something you know, have or are; two factors from one class is not MFA
•
a stolen password on its own stops being enough to sign in
•
a shared seed and a 30-second window can be relayed by a proxy in real time
•
SIM swap and telecom interception make SMS the weakest second factor
•
the authenticator signs the origin, so a look-alike site cannot replay it
•
the server stores only a public key, so a database dump yields nothing to replay
•
reused breach credentials replayed at scale, which is not guessing
•
different messages, status codes or response times leak which accounts exist
•
a predictable or sequential session identifier is an authentication bypass
•
failing to issue a new session at login is session fixation
•
Secure, HttpOnly and SameSite each prevent a different, specific attack
•
clearing the cookie leaves the session record usable by anyone holding a copy
K. Password and credential storage
•
storage must be one-way; encryption is reversible by whoever holds the key
•
SHA-256 is designed to be fast, which is precisely the attacker's advantage
•
bcrypt, scrypt, PBKDF2 and Argon2id are deliberately and tunably slow
•
a unique random salt defeats rainbow tables and hides identical passwords
•
a secret held outside the database, so a table dump alone is not crackable
•
raise the cost parameter as hardware improves, re-hashing on next login
•
input past 72 bytes is silently ignored, so long passphrases collide
•
NIST guidance favors long passphrases and drops forced periodic rotation
•
reject known-compromised passwords instead of adding character-class rules
L. Tokens: OAuth 2.0, OIDC and JWT
•
the payload is Base64url and readable by anyone holding the token
•
trusting the token's own algorithm header lets an attacker strip the signature entirely
•
verifying with the public key as an HMAC secret forges arbitrary tokens
•
a correct signature from the wrong issuer, or for another audience, is still wrong
•
a stateless token stays valid until it expires; you need short TTLs or a deny list
•
it delegates access on your behalf; on its own it is not a login protocol
•
the ID token is the assertion about the user; an access token never is
•
the code travels through the browser, the token through the back channel
•
a verifier and its challenge stop an intercepted authorization code from being redeemed
•
an unguessable value ties the callback to the request and blocks login CSRF
•
reuse of an already-rotated refresh token signals theft and revokes the whole family
•
localStorage is readable by any injected script; an HttpOnly cookie is not
M. Cryptography fundamentals
•
Base64 and hex are reversible by anyone, with no key involved
•
a digest cannot be inverted, only guessed at and compared
•
one shared key versus a keypair, and the order-of-magnitude speed gap
•
AES is a block cipher; the mode of operation decides what the ciphertext leaks
•
identical plaintext blocks produce identical ciphertext blocks
•
reusing a nonce under one key in GCM or CTR destroys confidentiality and authenticity
•
GCM and ChaCha20-Poly1305 provide confidentiality and integrity as a single primitive
•
a MAC proves a shared secret; a signature proves a private key and is non-repudiable
•
ordinary random functions are predictable; tokens need a cryptographic generator
•
ephemeral key agreement means a later private-key theft cannot decrypt old traffic
•
recorded traffic is the post-quantum threat, so key agreement migrates first
N. Key management and cryptographic misuse
•
use a vetted library and a standard construction; novel crypto fails under review
•
a human secret must pass through a KDF before it can serve as key material
•
rotation bounds the window a compromised key covers, and needs a re-wrapping plan
•
a data key encrypts the data; a managed root key encrypts the data key
•
the key operates inside hardware and never exists in application memory
•
distinguishable decryption failures let an attacker recover plaintext without the key
•
secret-dependent branches and comparisons leak; use constant-time primitives
•
a low-entropy identifier such as an email or phone number is trivially brute-forced
O. PKI and TLS
•
a CA asserts that this public key belongs to this hostname
•
the client validates a path from the leaf to a root it already trusts
•
hostname match, validity dates, chain and revocation are independent checks
•
CRLs go stale and OCSP fails open; stapling and short lifetimes work better
•
pinning defeats a mis-issuing CA and bricks the client when the pinned key changes
•
authenticate the server, agree a fresh key, then switch to symmetric encryption
•
static RSA key exchange and the legacy ciphers are gone, making forward secrecy mandatory
•
both peers present certificates, so the client is authenticated by key rather than password
•
an attacker forces plaintext or an older version; HSTS and a version floor stop it
P. Network and infrastructure security
•
it tracks connections, so return traffic needs no separate inbound rule
•
outbound filtering is what turns an implant or an SSRF into a dead end
•
a flat network converts one compromised host into access to everything
•
one observes and alerts, the other sits inline and can drop the traffic
•
signatures buy time to patch; they never fix the vulnerable code
•
address translation hides addresses; it enforces no security policy
•
it gives record integrity and origin authentication, not confidentiality
•
an open admin service with a default credential is the entire breach
Q. Cloud, container and Kubernetes security
•
the provider secures the infrastructure; configuration and data stay yours
•
a wildcard action on a wildcard resource is the cloud equivalent of running as root
•
an assumed role expires; a static access key committed to a repo does not
•
misread bucket policies and ACLs are a recurring whole-dataset exposure
•
credentials reachable over plain HTTP from inside the workload
•
namespaces and cgroups share one kernel, so a kernel bug is a full escape
•
a root process in a container plus a host mount is a host compromise
•
scanning finds known CVEs; admission-time signature checks enforce provenance
•
Secrets are Base64, not encrypted, unless encryption at rest is switched on
•
every pod can reach every pod until a NetworkPolicy says otherwise
R. Software supply chain
•
most of your shipped code is code nobody on the team has read
•
a package whose name is one character away from the one you meant
•
a public package shadowing a private name the resolver prefers
•
pinning plus integrity hashes is what makes a build reproducible
•
installing a package executes its code before you ever import it
•
a component inventory is what lets you answer a new CVE in minutes rather than weeks
•
attest how an artifact was built, and verify that attestation at deploy time
•
build runners hold deploy credentials and are a first-class target
S. Secure SDLC and security testing
•
a flaw caught in design costs orders of magnitude less than one caught in production
•
analyzes source without executing it; strong on patterns, noisy with false positives
•
attacks the running application; sees real behavior, misses code it cannot reach
•
matches your declared dependencies against known-vulnerability databases
•
malformed input at volume, which is how parser and memory bugs actually surface
•
a human chaining several weaknesses versus an automated signature sweep
•
every fixed vulnerability becomes a test that fails if it ever returns
•
a published reporting channel and a fix timeline, not legal threats
T. Attack lifecycle, detection and incident response
•
recon, weaponize, deliver, exploit, install, command and control, act on objectives
•
ATT&CK catalogs observed tactics and techniques, so you can map detection coverage
•
phishing, exposed services, valid accounts and trusted third parties dominate
•
after access, the attacker's next goal is surviving a reboot and a password reset
•
reused local administrator credentials are how one host becomes the whole estate
•
unusual volume, destination and timing over egress, not suspicious file names
•
SP 800-61r3 (April 2025) rebuilt the life cycle on the six CSF 2.0 Functions — Govern, Identify, Protect, Detect, Respond, Recover — and maps the older preparation / detection & analysis / containment-eradication-recovery / post-incident phases onto them
•
containment prevents an incident expanding and comes first; deliberately delaying it to watch an attacker and gather evidence is a legal-sign-off decision, not a default, because the delay lets them escalate
•
three copies, two media, one offline; a mounted backup gets encrypted too
U. Secrets, logging and data protection
•
git history keeps a committed key forever, so rotate rather than delete
•
central storage with an access policy, an audit trail and automated rotation
•
environment values leak through the process tree, crash dumps and logs
•
catch the credential before the push, and keep scanning every push afterwards
•
a leaked secret is compromised whether or not you saw anyone use it
•
authentication, authorization failures and admin actions, with enough context
•
tokens, passwords and card numbers get replicated across every log store
•
data you never collected cannot be breached, subpoenaed or mishandled
V. Email and domain security
•
the base protocol lets any host claim any sender address
•
a DNS record listing the hosts permitted to send, checked against the envelope sender
•
a signature over selected headers and the body, verified with a public key published in DNS
•
a policy layered on SPF and DKIM, plus aggregate reporting back to the domain owner
•
SPF or DKIM must pass for the visible From domain, not merely for some domain
•
start at none for visibility, then quarantine, then reject
•
a sender logo requires DMARC at enforcement and, at some mailboxes, a verified mark
W. Memory safety and the low-level weakness class
•
the program reads or writes memory it does not own
•
writing past a fixed buffer overwrites saved registers and the return address
•
corrupting allocator metadata escalates into an arbitrary write
•
a dangling pointer used after the allocation was handed to someone else
•
a wrapped size calculation allocates less than the copy will write
•
user data used as a format specifier both reads and writes process memory
•
randomize the layout, mark data non-executable, detect a smashed stack
•
bounds checks or ownership rules trade runtime or compile cost for safety
X. Privacy, compliance and governance
•
an audit proves controls exist, not that they stop an attacker
•
personal data needs a stated basis and may not drift to a new purpose
•
the deadline runs from awareness, not from the day you finish the fix
•
the smaller the cardholder-data environment, the smaller the assessment
•
health data plus identifiers, requiring access control and audit logs
•
the report tests the controls you defined, operating over a period
•
deletion that misses derived copies and backups is not deletion
Keentune is not affiliated with or endorsed by the organizations whose documentation informs these maps.
All about Security practice
Also on your phone
App StoreGoogle Play
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.
© 2026 SportaApp LLC