How to pass the Provyn security fundamentals assessment

What the assessment tests

Security fundamentals questions are written for backend and full-stack engineers, not penetration testers. The goal is to assess whether you write code that is secure by default — not whether you can find vulnerabilities in other people's code for a living.

The highest-weighted area is authentication and session management. OAuth 2.0 flows, JWT validation, and session token handling appear on every attempt. Second highest is injection — SQL injection, command injection, and the structural reason parameterised queries prevent them.

OWASP Top 10: the injection family

SQL injection is prevented by parameterised queries (prepared statements), not by escaping. An ORM does not automatically prevent injection if you pass user input directly into a raw query string. The assessment will show you a code snippet and ask whether it is vulnerable — if user input is concatenated into a SQL string, it is vulnerable, regardless of what language or library is used.

XSS is prevented by output encoding, not input sanitisation. The distinction matters: sanitising input strips characters, but encoding output tells the browser to treat the string as data, not code. React's JSX is not XSS-proof by default — dangerouslySetInnerHTML with user input is an XSS vulnerability.

JWT and OAuth 2.0

JWT structure: header.payload.signature. The signature is computed over the header and payload using the signing key. If the 'alg' field is set to 'none', there is no signature — any server that accepts alg:none tokens is critically vulnerable. The assessment will ask you to identify this vulnerability.

OAuth 2.0 flows: Authorization Code flow is for server-side apps that can keep a client secret. PKCE (Proof Key for Code Exchange) extends Authorization Code for SPAs and mobile apps that cannot keep a secret. Implicit flow is deprecated. Know why: it puts the access token in the URL fragment, which is logged by browsers and servers.

Cryptography: what engineers actually need

Passwords must be hashed with bcrypt, Argon2, or scrypt — never SHA-256, MD5, or any fast hash. The assessment will present a password-storage implementation and ask if it is secure. If the hash is fast, it is wrong.

TLS: the handshake establishes a shared session key using asymmetric cryptography (RSA or ECDHE), then switches to symmetric encryption (AES-GCM) for bulk data because symmetric ciphers are orders of magnitude faster. The assessment will ask why TLS uses both — the answer is performance combined with forward secrecy.

Three-day prep plan

Day one: read the OWASP Top 10 list and for each item, think of a code example that is vulnerable and how to fix it.

Day two: draw the Authorization Code flow on paper: client, authorization server, resource server. Know what each token (authorization code, access token, refresh token, ID token) is used for.

Day three: review secrets management. Know the difference between environment variables (acceptable for server-side secrets), client-side storage (never for secrets), and a vault (best practice for production).