Why I Took the Secops Group Certified Application Security Practitioner Certification (And You Should Consider It Too)
Anyone who’s done hands-on application security knows that real learning starts outside of textbooks - in labs, in bugs you’ve triaged, in secure code reviews you’ve agonized over. That’s exactly why, last year, I signed up for the Certified Application Security Practitioner (CAP) exam by The SecOps Group - and I’ll tell you this straight: it was one of the most clarifying steps in my AppSec career.
This exam is not about machine memorization - it’s about understanding how apps break and importantly, how they shouldn’t. In 60 minutes online, you’re quizzed on scenarios that reflect real-world code and configuration pitfalls - from SQL injection to insecure headers and auth flaws.
💡 Why it matters:
Builds confidence before tackling real apps
Gives a portable credential you can share with employers
Forces you to structure knowledge you may already feel but haven’t documented
Over the next posts, I’ll take you behind the syllabus, share real practice questions (my personal bank of ~30 MCQs!), and show you how to study smart - not just hard.
👉 Drop a comment if you want a printable study checklist!
First set of practice MCQs
✅ Question 1 — Session Token Reuse
A tester steals a user’s session token and is able to reuse it repeatedly, even though the application sets short expiration times. What technique did the tester most likely use?
A) Cross-Site Request Forgery (CSRF)
B) Session Fixation
C) Pass-the-Cookie Attack
D) Token Sidejacking
✔ Correct Answer: C) Pass-the-Cookie Attack
Explanation:
In this scenario, the attacker has taken a valid session token and continued to reuse it regardless of the expiration policy. That’s a Pass-the-Cookie Attack — the attacker simply presents the stolen cookie to the server, which treats it as valid.
Why the Other Options Don’t Fit:
CSRF doesn’t involve stealing session tokens.
Session Fixation involves setting a session ID before login, not stealing one post-login.
Token Sidejacking refers to capturing tokens in transit, but this question focuses on reuse of an already valid token.
How to Prevent This
✔ Secure & HttpOnly Cookies — block JavaScript access and reduce theft via XSS.
✔ SameSite=Lax/Strict — limits cookie sending in cross-site contexts.
✔ Rotate Tokens on Login/Privilege Change — issue fresh tokens instead of reusing old ones.
✔ Monitor Session Behavior — detect multiple uses from different IPs/devices.
Concise Example (Express.js):
res.cookie("session", token, {
httpOnly: true,
secure: true,
sameSite: "Strict",
maxAge: 30 * 60 * 1000 // 30 minutes
});
✅ Question 2 — Unsafe API Query
An API returns all records when the filter parameter is changed to id>=0 OR 1=1, exposing sensitive data. What’s the primary vulnerability?
A) Insecure Direct Object Reference (IDOR)
B) NoSQL Injection
C) SQL Injection via unsafe query
D) Improper Data Filtering Leading to Mass Assignment
✔ Correct Answer: C) SQL Injection via unsafe query
Explanation:
The injected condition OR 1=1 always evaluates to true, which tells us the API is directly embedding user input into database queries — classic SQL Injection.
Why Not the Other Options:
IDOR is about unauthorized references, not query manipulation.
NoSQL Injection targets NoSQL engines — here the syntax is SQL.
Mass Assignment is about setting fields in an object, not expanding result sets.
How to Prevent SQL Injection
✔ Use Parameterized Queries / Prepared Statements — never concatenate input into SQL.
✔ Validate & Sanitize Input — restrict data types and allow-lists for operators.
✔ Use an ORM — reduces raw SQL construction.
✔ Implement Access Controls — ensure users only see data they’re allowed to.
Concise Example (Python):
query = "SELECT * FROM users WHERE id > ?"
cursor.execute(query, (filter_value,))
✅ Question 3 — Password Reset Logic Flaw
A tester changes the email field in a password reset request to another user’s email and successfully resets the victim’s password. What’s the root cause?
A) Lack of CSRF token validation
B) Insecure Direct Object Reference (IDOR)
C) Missing authentication and authorization checks
D) Race condition in password reset logic
✔ Correct Answer: C) Missing authentication and authorization checks
Explanation:
If anyone can submit an email to reset anyone else’s password without proving they own it, the logic is missing basic identity verification.
Why Not the Others:
CSRF doesn’t apply here since no user session is checked.
IDOR is about direct object access, not missing verification.
Race conditions involve timing issues, not lack of authentication.
How to Secure Password Resets
✔ Generate One-Time, Time-Limited Tokens — send via email or SMS.
✔ Avoid Accepting Email Directly for Reset — map requests to an authenticated/verified identity.
✔ Require Additional Verification (MFA) — add a second factor where feasible.
✔ Monitor and Throttle reset attempts.
Pattern (Pseudo):
User requests reset → Server sends unique token to email → Token must be presented to reset
✅ Question 4 — File Upload Execution
A tester uploads a .jpg file, renames it to profile.jpg.php, and executes arbitrary code on the server. What is the most likely cause?
A) The app fails to verify actual file types and executes .php files even if disguised.
B) Server validation checks only extensions and doesn’t block double extensions.
C) Files are stored in a public directory and allow direct execution.
D) The web server executes .jpg images as PHP based on content type.
✔ Correct Answer: A) The app fails to verify actual file types and executes .php files even if disguised.
Explanation:
The server allowed a file with a .php extension to run as code, despite it being uploaded through a process that tried to treat it as an image. The root issue is trusting file names/extensions instead of checking real file contents and execution settings.
Why Not the Others:
Just checking extensions (B) is insufficient if execution is still allowed.
Storing public files (C) is risky, but execution policy is the core flaw.
MIME type (D) doesn’t control execution — file handlers do.
How to Prevent File Upload Exploits
✔ Verify File Type by Content (magic bytes) — not just name.
✔ Store Uploads Outside the Executable Web Root — no direct execution.
✔ Disable Script Execution in Upload Folders (e.g., using server configs).
✔ Randomize File Names — avoid predictable access.
Directory blocking example (Apache .htaccess):
php_admin_flag engine off
✅ Question 5 — JWT Weak Signing Key
An attacker modifies a JWT to promote their role to admin, then successfully signs it with "admin" as the secret key. What does this indicate?
A) JWT signature validation is disabled
B) The server accepts the “none” algorithm
C) The server is using a weak signing key that can be brute-forced
D) The application doesn’t enforce expiration (exp)
✔ Correct Answer: C) The server is using a weak signing key that can be brute-forced
Explanation:
JWT signatures protect the integrity of the token. If the secret is easy to guess (like "admin"), an attacker can sign forged tokens and the server will accept them. This is a weak key problem, not a missing validation logic.
Why Not the Others:
Signature disabled would mean no signature needed at all — not the case here.
“none” algorithm bypasses signing entirely — this attacker used a guessable key.
Missing
expaffects token lifetime, not tampering protection.
How to Secure JWT Usage
✔ Use Strong Secrets or Asymmetric Keys (RS256) — long, random, unguessable.
✔ Enforce Signature Verification Strictly — reject unsigned/invalid tokens.
✔ Add Expiration and Refresh Logic (exp, iat) — limit token lifespan.
✔ Protect Secret Keys — store them securely (env vars, vaults).
Concise Signing Example (Python):
token = jwt.encode(payload, SECRET_KEY, algorithm="HS256")
