Certified AppSec Practitioner (CAP) Exam: A Comprehensive Overview

I just passed the Certified AppSec Practitioner (CAP) exam, and I'm excited to share my experience, and resource used to prepare and important topics!.

Something I Wanna Say:

I believe the most exciting way to prepare for this exam is to dive into each topic one by one! We need to really understand each topic and sometimes we need to practice it by doing labs. And guess what? There are free labs available at PortSwigger! For this exam, I recommend tackling one lab for each topic. It worked wonders for me, and it can for you too!

About the Exam:

Certified AppSec Practitioner (CAP) is an entry-level exam to test candidates’ knowledge on the core concepts of application security:

• Number of Questions: 60

• Exam Type: Multiple-choice questions

• Passing score: 60% (successfully passed), over 75% (passed with a merit)

• Test duration: 1 hour

From the SecOps official website, we are presented with this exam topic information:

Echo:

The Certified Application Security Practitioner (CAP) exam evaluates knowledge across both defensive and offensive aspects of application security. This dual focus ensures that candidates are equipped not only to safeguard applications but also to understand and identify potential vulnerabilities in real-world scenarios.

On the defensive side, the exam emphasizes critical application hardening techniques. Candidates are expected to demonstrate a solid understanding of security headers, including their implementation and practical use cases. Headers like Content Security Policy (CSP) help prevent cross-site scripting (XSS) attacks, while Strict-Transport-Security (HSTS) enforces HTTPS to protect against protocol downgrade attacks. Other key headers, such as X-Frame-Options and X-Content-Type-Options, are crucial in preventing clickjacking and MIME type sniffing, respectively. The defensive portion of the exam also assesses knowledge of secure coding practices, proper input validation mechanisms, and strategies to mitigate security misconfigurations, a common vulnerability in web applications.

The offensive side of the exam delves deeply into vulnerability identification and exploitation, making it a practical test of hands-on application security skills. Candidates will encounter realistic scenarios involving tools like Burp Suite Repeater and Intruder, designed to simulate the process of probing and attacking web applications. For example, you might be presented with a Burp Suite Repeater request showing an attempted attack—such as an SQL injection payload or a command injection attempt—and be asked to identify the type of attack being performed. These scenarios could also include analyzing crafted requests, malicious input, or even screenshots of tool outputs to determine whether the vulnerability being exploited is XSS, broken authentication, or something else from the OWASP Top 10.

Additionally, the offensive section tests your ability to recognize subtle attack patterns. You might encounter screenshots showing:

A Burp Suite Intruder brute force attack on login credentials and be asked to deduce the attack type and its implications.

A payload attempting to exploit Cross-Site Request Forgery (CSRF), and you’ll need to assess the application’s level of protection.

An HTTP request header or URL parameter crafted for Server-Side Request Forgery (SSRF) or IDOR, with questions asking you to explain the underlying issue.

These questions aren’t limited to recognizing the vulnerabilities—they often require you to consider the broader implications and recommend appropriate mitigation strategies. For instance, if an SQL injection attack is detected, you may need to identify which database defenses, such as parameterized queries, input sanitization, or web application firewalls (WAFs), would be most effective.

The OWASP Top 10 is a cornerstone of this exam, ensuring you have a strong foundation in understanding the most prevalent and impactful vulnerabilities in modern applications. However, the CAP exam goes beyond theory—it challenges candidates to think critically, analyze real-world scenarios, and apply their knowledge to solve security problems effectively

Going Deep:

For each exam section (Defensive or Offensive), I’ll provide:

1. A brief overview: A concise explanation of the topics and its importance.

2. Valuable resources: Links to materials that helped me understand the topics better.

3. Exam insights: Including the approximate number of questions I encountered related to each topic (note: this may vary).

This approach will ensure you have a clear understanding, access to useful resources, and an idea of how much weight each topic smight carry in the exam.

Defensive Section:

Topic 1: Input Validation Mechanisms

Definition:

Input validation is a critical security measure to ensure that incoming data from users, systems, or other sources is safe, properly formatted, and adheres to the expected format. Poor or absent input validation is a leading cause of many application vulnerabilities, such as SQL injection, Cross-Site Scripting (XSS), and buffer overflows.

Key Concepts

1. Blacklisting:

   • A defensive approach where specific "disallowed" inputs (e.g., dangerous characters like <script> for XSS) are blocked.

   • Downside: It’s challenging to account for all potential malicious inputs, making it less robust.

2. Whitelisting:

   • A preferred approach that only allows specific, pre-approved inputs (e.g., alphanumeric characters or fixed formats like email addresses).

   • Example: Restricting a username field to only letters and numbers, rejecting anything else.

   • Advantage: It's more secure because it narrows down acceptable inputs.

Why Input Validation Matters

• Prevention of Injection Attacks: Validating inputs stops malicious data from altering queries or commands.

• Data Integrity: Ensures data stored or processed remains in a valid and predictable format.

• Application Stability: Avoids unexpected crashes caused by malformed or malicious inputs.

Useful Resources:

• You can skim through this OWASP Input Validation Cheat Sheet

Question encountered during the exam: 1

Topic 2: Encoding, Encryption, and Hashing

Definition:

Understanding encoding, encryption, and hashing is critical in application security as these techniques help ensure data protection, integrity, and secure communication. While they are often confused, each serves a unique purpose.

Key Concepts

1. Encoding

   • Purpose: Encoding is used to transform data into a different format to ensure that it can be safely transmitted or processed. It is not intended for security but rather for data integrity and compatibility.

   • Example Use Case: Encoding data to be safely transmitted in a URL or HTML without introducing vulnerabilities.

     • Example: Encoding <script> as <script> in HTML to prevent XSS.

   • Reversibility: Encoding is reversible; the original data can be easily decoded.

   • Common Encoding Schemes:

     • Base64

     • URL encoding (%20 for spaces)

     • HTML encoding (< for <)

2. Encryption

   • Purpose: Encryption is used to secure data by converting it into an unreadable format (ciphertext) using a key. It ensures data confidentiality.

   • Types of Encryption:

     1. Symmetric Encryption:

        • The same key is used for both encryption and decryption.

        • Examples: AES (Advanced Encryption Standard), DES.

        • Use Case: Encrypting data at rest, such as database records.

     2. Asymmetric Encryption:

        • Uses a pair of keys: a public key for encryption and a private key for decryption.

        • Examples: RSA, Elliptic Curve Cryptography (ECC).

        • Use Case: Secure data transmission, such as HTTPS using TLS.

   • Reversibility: Encryption is reversible if the correct key is provided.

   • Best Practices:

     • Use strong algorithms like AES-256 for symmetric encryption.

     • Rotate keys periodically and store them securely using a Key Management System (KMS).

     • Avoid outdated encryption algorithms like DES or MD5 for security purposes.

3. Hashing

   • Purpose: Hashing converts data into a fixed-length string (hash value) to verify integrity or store sensitive information securely. It is primarily used for one-way transformation.

   • Examples of Hashing Algorithms:

     • Secure: SHA-256, SHA-3.

     • Deprecated: MD5, SHA-1 (no longer secure against collision attacks).

   • Reversibility: Hashing is irreversible; it is impossible to retrieve the original data from the hash value.

   • Use Cases:

     • Storing passwords securely in databases.

     • Ensuring data integrity by comparing hash values (e.g., file checksums).

   • Salting and Peppering:

     • Add unique salt to passwords before hashing to prevent rainbow table attacks.

     • Use pepper (a secret key) stored separately for additional security.

Key Differences

Example Scenarios

Encryption Use Case: A banking application encrypts sensitive data like customer account numbers before storing them in the database. This ensures that even if the database is compromised, the attacker cannot read the information without the decryption key.

Hashing Use Case: The same application hashes user passwords with a secure algorithm like bcrypt or Argon2. Even if the password database is leaked, attackers cannot reverse the hash to retrieve the original passwords.

Encoding Use Case: The application encodes special characters in URLs or HTML to prevent injection attacks, ensuring the data is safely transmitted or displayed.

Useful Resources:

• You can skim through this Okta

Question encountered during the exam: 3

Topic 3: Security Best Practices and Hardening Mechanisms

Focusing on:

• Same Origin Policy

• Security Headers

Definition:

1. Same Origin Policy (SOP):

   The same-origin policy is a web browser security mechanism designed to prevent malicious websites from accessing sensitive data from other websites. It restricts scripts on one origin from interacting with resources from a different origin unless explicitly allowed (via HTTP HEADERS).

   In web security, a resource is a page, a cookie, a file…ext.

   an origin is a combination of three components from a URL:

   1. URI Scheme (e.g., http, https)

   2. Domain (e.g., example.com)

   3. Port Number (e.g., 80, 443)

For example, in the URL http://example.com:8080/path, the origin consists of:

• Scheme: http

• Domain: example.com

• Port: 8080

The table below explains how the policy is applied when this URL tries to access resources from other URLs:

Note: Internet Explorer does not consider port numbers when enforcing the same-origin policy, so access might be permitted in IE for URLs with different ports.

2. Security Headers

   While the same-origin policy is fundamentally a browser-enforced security mechanism, HTTP secure headers provide additional layers of control over cross-origin resource sharing. These headers allow developers to define exceptions or reinforce the default behavior, enhancing security and flexibility.

   Below a table that includes both HTTP headers and secure cookie attributes for implementing SOP and mitigating XSS, CSRF, Clickjacking, and other attacks:

   | Header/Attribute | Purpose | Attack Mitigated | Example | | --- | --- | --- | --- | | Content-Security-Policy | Controls resource loading (scripts, styles, etc.). | Mitigates XSS and Clickjacking. | Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.com; object-src 'none'; | | X-Frame-Options | Prevents embedding in iframes. | Mitigates Clickjacking. | X-Frame-Options: SAMEORIGIN | | X-Content-Type-Options | Prevents MIME type sniffing. | Mitigates XSS. | X-Content-Type-Options: nosniff | | Strict-Transport-Security (HSTS) | Enforces HTTPS and prevents protocol downgrade. | Mitigates MITM attacks. | Strict-Transport-Security: max-age=31536000; includeSubDomains | | Referrer-Policy | Controls the Referer header in requests. | Protects sensitive referrer data. | Referrer-Policy: no-referrer | | Access-Control-Allow-Origin | Defines allowed origins for cross-origin requests. | Enforces SOP and mitigates CSRF. | Access-Control-Allow-Origin: https://example.com | | Access-Control-Allow-Credentials | Allows cookies and credentials with CORS requests. | Ensures secure cross-origin access. | Access-Control-Allow-Credentials: true | | Access-Control-Allow-Methods | Specifies allowed HTTP methods for CORS. | Enforces SOP. | Access-Control-Allow-Methods: GET, POST, OPTIONS | | Permissions-Policy | Controls access to browser features (e.g., camera, mic). | Prevents abuse of sensitive APIs. | Permissions-Policy: camera=(), microphone=(), geolocation=() | | Expect-CT | Enforces certificate transparency for HTTPS. | Ensures certificate integrity. | Expect-CT: max-age=86400, enforce | | Cache-Control | Prevents caching of sensitive data. | Mitigates information leakage. | Cache-Control: no-store, no-cache, must-revalidate | | Pragma | Prevents caching (legacy support). | Mitigates information leakage. | Pragma: no-cache | | Set-Cookie + HttpOnly | Prevents JavaScript access to cookies. | Mitigates XSS. | Set-Cookie: sessionId=abc123; HttpOnly | | Set-Cookie + Secure | Ensures cookies are sent only over HTTPS. | Mitigates MITM attacks. | Set-Cookie: sessionId=abc123; Secure | | Set-Cookie + SameSite | Restricts cookies in cross-origin requests. | Mitigates CSRF. | Set-Cookie: sessionId=abc123; SameSite=Strict | | Set-Cookie + Domain | Restricts cookie to a specific domain. | Limits exposure. | Set-Cookie: sessionId=abc123; Domain=example.com | | Set-Cookie + Path | Restricts cookie to a specific URL path. | Limits scope. | Set-Cookie: sessionId=abc123; Path=/account | | Set-Cookie + Max-Age | Sets the cookie’s expiration in seconds. | Limits lifetime. | Set-Cookie: sessionId=abc123; Max-Age=3600 |

Useful Resources:

• Same Origin Policy: Portswigger, MDN

• Secure HTTP Header: OWASP

Question encountered during the exam: 15

Topic 4: Others

In this topic called others hahaha am going to talk about topics mentioned in the exam but was not necessarily in the exam topics:

• What is JWT, and its format

• common CMS software like wordpress ..ext

• Well-Known CVEs

Question encountered during the exam: 3

Offensive Section:

In this section I will not explain much, I would rather share with you best resources/labs that helped me grasp the offensive section of the exam

Main Topic: Understanding of OWASP TOP 10 Vulnerabilities

Critical Resources:

• The very OWASP TOP 10

• For each type of vulnerability listed in OWASP TOP 10 items, doing one Lab is must for that jump on : All Web Security Academy topics | Web Security Academy - PortSwigger

Question encountered during the exam: a lot