Sample questions
SecurityDifficulty 1
What is the difference between authentication and authorization?
- aAuthentication decides what a user may access; authorization verifies their identity
- bAuthentication verifies who the user is; authorization decides what they are allowed to do✓
- cThey are two different names for the same security process
- dAuthentication is used for people; authorization is used only for other services
Explanation:Authentication answers "who are you?" (login, credentials); authorization answers "what may you do?" (permissions, roles). Option (a) states it exactly backwards, which is the most common confusion between the two terms.
SecurityDifficulty 1
What is the fundamental difference between hashing and encryption?
- aHashing is faster; apart from speed they provide the same guarantees
- bEncryption is one-way, while a hash can be reversed with the right key
- cHashing is one-way by design; encryption is reversible by whoever has the key✓
- dHashing only works on passwords; encryption works on any kind of data
Explanation:A hash is a one-way digest: there is no key and no decrypt operation. Encryption is designed to be reversed with the key. Option (b) swaps the two concepts, and (d) is wrong because both operate on arbitrary data.
SecurityDifficulty 2
A support lead requests a screen where agents can see a customer's current password to help them log in. Why must this request be rejected?
- aProperly stored passwords are one-way hashed and cannot be shown✓
- bIt is acceptable as long as the screen is limited to senior support agents
- cIt is acceptable if every password view is recorded in an audit log
- dIt is fine if the screen is only ever served over an HTTPS connection
Explanation:Passwords must be stored as salted, slow one-way hashes, so a correctly built system is technically unable to display them. If a system can show a password, it is storing passwords wrong. Restricting viewers (b) or the transport (d) does not fix that root problem — support should trigger a password reset instead. Audit logging (c) records the abuse; it does not remove the exposure.
SecurityDifficulty 2
In password hashing, what does a unique per-user salt provide?
- aIt encrypts the stored hash so it cannot be read from the database
- bIt slows the hash function down, which is what blocks brute force by making each guess costly
- cIt allows the server to recover the original password when required
- dIdentical passwords get different hashes, and precomputed hash tables stop working✓
Explanation:The salt individualizes every hash: two users with the same password store different values, and attackers cannot use precomputed (rainbow) tables built in advance. Slowness (b) comes from the algorithm's cost factor, not from the salt, and nothing about hashing is reversible (c).
SecurityDifficulty 3
A user clicks "log out" and the app deletes the session cookie in the browser. A copy of the old cookie value captured earlier still works against the API. What is the flaw?
- aThe cookie was missing the Secure flag, so the browser could not delete it properly
- bLogout only removed the cookie on the client; the session was never invalidated on the server✓
- cNothing is wrong — a session can only end when its TTL expires
- dThe session id should have been kept in localStorage, which logout can clear reliably
Explanation:Logging out must invalidate the session server-side (delete or mark the session record) so that every copy of the identifier dies with it. Deleting the browser's cookie only affects that one client. Option (c) is wrong precisely because server-side session stores exist to allow immediate revocation.
SecurityDifficulty 1
What happens in a typical stored XSS attack?
- aThe attacker floods the server with requests until it stops responding
- bThe attacker reads arbitrary files such as configuration files directly from the server's disk
- cAttacker-supplied script is saved by the application and later runs in other users' browsers✓
- dThe attacker intercepts and modifies traffic between the user and the server
Explanation:In stored XSS, malicious script submitted as content (a comment, a profile field) is persisted and served to other users, executing in their browsers with the site's privileges. It is a client-side code execution issue — not server file access (b) or traffic interception (d).