The SecOps Group CAP Certified AppSec Practitioner Exam Exam Practice Test

The request is a GET to /dashboard.php with a purl parameter (http://attacker.com). The response is a 302 Found redirect with a Location: http://attacker.com header, indicating the server redirects the client to the URL specified in the purl parameter. Let’s evaluate the statements:

Option A ("Application is likely to be vulnerable to Open Redirection vulnerability"): Correct. Open Redirection occurs when an application redirects to a user-supplied URL without validation. Here, the purl parameter (http://attacker.com) is directly used in the Location header, allowing an attacker to redirect users to a malicious site (e.g., for phishing). This is a classic Open Redirection vulnerability if the application does not restrict redirects to trusted domains.

Option B ("Application is vulnerable to Cross-Site Request Forgery vulnerability"): Incorrect. CSRF involves tricking a user into making an unintended request (e.g., via a malicious form). This response does not indicate a CSRF issue; there’s no evidence of state-changing actions or lack of CSRF tokens.

Option C ("Application uses an insecure protocol"): Incorrect. The request is made over HTTP, and the redirect is to an HTTP URL (http://attacker.com), which is insecure, but the response itself does not indicate the protocol used for the initial request. The server could be using HTTPS for the initial response; the insecure protocol is in the redirect destination, which relates to the Open Redirection issue, not the application’s protocol usage broadly.

Option D ("All of the above"): Incorrect, as only A is true.

The correct answer is A, aligning with the CAP syllabus under "Open Redirection Vulnerabilities" and "URL Redirection Attacks."References: SecOps Group CAP Documents - "Open Redirection," "Input Validation for Redirects," and "OWASP Top 10 (A10:2021 - Server-Side Request Forgery)" sections.

CORS (Cross-Origin Resource Sharing) is a mechanism that allows servers to specify which origins can access their resources, enhancing security for cross-origin requests. A common misconfiguration occurs with theAccess-Control-Allow-OriginandAccess-Control-Allow-Credentialsheaders. WhenAccess-Control-Allow-Originis set to * (wildcard, allowing all origins), it permits any domain to make requests. However, ifAccess-Control-Allow-Credentialsis set to true (allowing credentials like cookies or HTTP authentication), this creates a security risk. Browsers will block such requests because sending credentials with a wildcard origin violates CORS security policies, but an attacker could exploit this misconfiguration to trick a victim’s browser into making unauthorized requests if other controls are absent.

Option A is correct because the combination of Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true is exploitable, as it enables potential credential leakage or unauthorized access. Option B is incorrect because Access-Control-Allow-Credentials: false disables credential sending, reducing exploitability. Option C is incorrect because the value of Access-Control-Allow-Credentials is not irrelevant; it must be false with a wildcard origin to comply with security standards. Option D ("All of the above") is incorrect as only A holds true. This is a key topic in the CAP syllabus under "CORS Misconfiguration" and "Client-Side Security."References: SecOps Group CAP Documents - "CORS Configuration," "Security Misconfigurations," and "OWASP Secure Headers" sections.

GraphQL Introspection is a built-in feature of GraphQL that allows clients to query the schema of a GraphQL API at runtime. This process involves sending introspection queries (e.g., __schema or __type) to retrieve information about the API’s structure, including available types, fields, queries, mutations, and their relationships. This capability is powerful for developers to explore and document APIs but poses a security risk if left enabled in production, as attackers can use it to map out the entire API structure and identify potential attack vectors.

Option A ("A technique for testing the compatibility of the GraphQL API with other systems"): Incorrect, as introspection is about schema discovery, not compatibility testing.

Option B ("A technique for testing the performance of the GraphQL API"): Incorrect, as performance testing involves load or stress testing, not schema exploration.

Option C ("A technique for discovering the structure of the GraphQL API"): Correct, as introspection is specifically designed to expose the API’s schema and structure.

Option D ("A technique for testing the security of the GraphQL API"): Incorrect, as security testing is a separate process; introspection itself is a feature, not a security test.

The correct answer is C, aligning with the CAP syllabus under "GraphQL Security" and "API Introspection."References: SecOps Group CAP Documents - "GraphQL Fundamentals," "Introspection Risks," and "OWASP API Security Top 10" sections.

Let’s evaluate the two statements about NoSQL injection:

Statement A: NoSQL databases (e.g., MongoDB, Cassandra) are designed for scalability and flexibility, often sacrificing strict consistency for performance (e.g., eventual consistency in distributed systems). Unlike traditional SQL databases, they do not enforce rigid relational constraints, which simplifies scaling but does not eliminate the risk of injection attacks. Even without SQL syntax, NoSQL databases are vulnerable to injection if user input is not sanitized (e.g., in MongoDB, injecting $where or $ne operators). This statement is true.

Statement B: NoSQL database queries are typically written in the application’s programming language (e.g., JavaScript for MongoDB), using a custom API (e.g., MongoDB’s query API), or formatted in standards like JSON, XML, or LINQ. For example, a MongoDB query might look like db.collection.find({ "key": input }), where input is a JSON-like structure. This statement accurately describes how NoSQL queries are constructed and is true.

Option A ("A is true, and B is false"): Incorrect, as both statements are true.

Option B ("A is false, and B is true"): Incorrect, as both statements are true.

Option C ("Both A and B are false"): Incorrect, as both statements are true.

Option D ("Both A and B are true"): Correct, as both statements accurately describe NoSQL databases and their vulnerability to injection.

The correct answer is D, aligning with the CAP syllabus under "NoSQL Injection" and "Database Security."References: SecOps Group CAP Documents - "NoSQL Injection Vulnerabilities," "Database Query Security," and "OWASP Top 10 (A03:2021 - Injection)" sections.

The password reset mechanism now includes a one-time random token alongside the userId in the reset link: https://example.com/reset_password?userId=5298 &token=70e7803e-bf53-45e1-8a3f-fb15da7de3a0. Let’s evaluate the effectiveness of this mechanism:

Analysis: The inclusion of a one-time random token (e.g., 70e7803e-bf53-45e1-8a3f-fb15da7de3a0) is a best practice for secure password reset mechanisms. This token should be unique, unpredictable, and tied to the specific user’s reset request (e.g., stored in the database with an expiration time). When the user clicks the link, the application should verify that the token matches the one associated with the userId and that it hasn’t been used or expired.

Preventing Arbitrary Resets: Without the token, an attacker could manipulate the userId (e.g., to 5299) to reset another user’s password (as seen in Question 45). However, with the token, the attacker would need to guess the correct token for the targeted userId, which is computationally infeasible if the token is sufficiently random (e.g., a UUID or cryptographically secure random string) and properly validated. This prevents unauthorized password resets.

Additional Considerations: The link uses https://, ensuring a secure channel (unlike Question 45). The message "If the email exists..." prevents username enumeration, as discussed previously.

Option A ("True"): Correct, as the one-time random token, if implemented correctly (e.g., validated server-side, single-use, time-limited), prevents an attacker from resetting arbitrary users’ passwords.

Option B ("False"): Incorrect, as the mechanism is secure with the token.

The correct answer is A, aligning with the CAP syllabus under "Secure Password Reset" and "Token-Based Authentication."References: SecOps Group CAP Documents - "Password Reset Security," "Token Generation Best Practices," and "OWASP Forgot Password Cheat Sheet" sections.

SQL Injection (SQLi) occurs when an attacker injects malicious SQL code into a query by manipulating user input (e.g., ' OR '1'='1'), allowing unauthorized data access or manipulation. Let’s evaluate the defenses:

Option A ("Using a Web Application Firewall (WAF)"): A WAF can detect and block SQL injection attempts by filtering malicious patterns (e.g., ' OR '1'='1'), but it is not the primary defense. WAFs can be bypassed with sophisticated attacks (e.g., encoded payloads), and they are a secondary layer, not a fix for the root cause in the application code.

Option B ("Prepared Statements with Parameterized Queries"): Correct. Prepared statements with parameterized queries separate SQL code from user input by using placeholders (e.g., ? in SELECT * FROM users WHERE username = ?). The database engine handles the input as data, not executable code, preventing SQL injection. This is the industry-standard primary defense (recommended by OWASP and NIST) because it addresses the root cause by ensuring user input cannot alter the query structure.

Option C ("Use of NoSQL Database"): Switching to a NoSQL database (e.g., MongoDB) does not inherently prevent injection vulnerabilities. NoSQL databases can still be vulnerable to injection (e.g., MongoDB’s $where operator), and SQL injection applies to relational databases. This is not a defense against SQLi.

Option D ("Blacklisting Single Quote Character (‘)"): Blacklisting specific characters (e.g., ') attempts to block known malicious input, but it is ineffective as a primary defense. Attackers can bypass blacklists using alternate encodings (e.g., %27 for '), comments (e.g., --), or other techniques. Blacklisting is reactive and prone to evasion, unlike prepared statements.

The correct answer is B, aligning with the CAP syllabus under "SQL Injection Prevention" and "OWASP Top 10 (A03:2021 - Injection)."References: SecOps Group CAP Documents - "SQL Injection Defense," "Secure Coding Practices," and "OWASP SQL Injection Prevention Cheat Sheet" sections.

The vulnerability described is anInsecure Direct Object Reference (IDOR), where manipulating the order_id (e.g., 53870) allows unauthorized access to other users’ orders. The fixes proposed by Bob and John aim to obscure the numeric value of order_id to prevent easy guessing or manipulation:

Bob’s Fix (SHA1 Hash): Replaces order_id=53870 with order_id=1ff0fe6f1599536d1326418124a261bc98b8ea1 (SHA1 hash of 53870). While this obscures the original value, an attacker can still attempt to hash potential order IDs (e.g., 53871, 53872) and test them in the URL. If the application directly uses the hash to look up the order without validating the user’s authorization, the vulnerability persists. SHA1 is aone-way hash, but it does not inherently enforce access control.

John’s Fix (Base64 Encoding): Replaces order_id=53870 with order_id=NTM4NzA= (Base64 encoding of 53870). Base64 is a reversible encoding, and an attacker can easily decode NTM4NzA= back to 53870 using standard tools. If the application decodes it and uses the original value to fetch orders without authorization checks, the IDOR vulnerability remains.

Evaluation: Both fixes address the symptom (disclosing the numeric value) but fail to address the root cause: lack of authorization validation. The application must ensure that only the authenticated user can access their own orders, regardless of the order_id format (numeric, hashed, or encoded). Neither fix includes such a check, so the vulnerability persists.

Option A ("Both solutions are adequate to fix the problem"): Incorrect, as neither solution enforces authorization.

Option B ("Both solutions are inadequate and the vulnerability is still not fixed"): Correct, as both SHA1 hashing and Base64 encoding are superficial changes that do not prevent unauthorized access.

Option C ("Only John’s solution fixes the problem"): Incorrect, as John’s Base64 encoding is reversible and does not fix the IDOR issue.

Option D ("Only Bob’s solution fixes the problem"): Incorrect, as Bob’s SHA1 hashing also does not address the authorization flaw.

The correct answer is B, aligning with the CAP syllabus under "Insecure Direct Object References (IDOR)" and "Access Control Best Practices."References: SecOps Group CAP Documents - "IDOR Mitigation," "Cryptographic Hashing," and "OWASP Access Control Testing Guide" sections.

Clickjacking is an attack where a malicious site tricks a user into clicking on something by overlaying a transparent iframe containing a legitimate site, exploiting the user’s clicks (e.g., clicking a button). The goal is to prevent a page from being embedded in a frame or iframe by unauthorized sites. Let’s evaluate the headers:

Option A ("Strict-Transport-Security"): HTTP Strict Transport Security (HSTS) enforces HTTPS connections by instructing browsers to only use secure connections, preventing man-in-the-middle attacks over HTTP. It does not address framing or clickjacking.

Option B ("Access-Control-Allow-Origin"): This CORS header specifies which origins can access resources, mitigating cross-origin resource sharing issues, but it does not prevent framing or clickjacking.

Option C ("X-Frame-Options"): Correct. The X-Frame-Options header controls whether a page can be embedded in an iframe. Values like DENY (block all framing) or SAMEORIGIN (allow only same-origin framing) prevent clickjacking by stopping malicious sites from embedding the page in a frame. This is a standard defense against clickjacking.

Option D ("X-Content-Type-Options"): This header prevents MIME-type sniffing by forcing browsers to respect the declared content type (e.g., nosniff), but it does not address framing or clickjacking.

The correct answer is C, aligning with the CAP syllabus under "Clickjacking Prevention" and"Security Headers."References: SecOps Group CAP Documents - "Clickjacking Defense," "Security Headers," and "OWASP Secure Headers Project" sections.

SAML (Security Assertion Markup Language) is an XML-based standard for authentication and authorization, commonly used for single sign-on (SSO). Its reliance on XML and the complexity of its trust model make it vulnerable to several attacks:

Option A ("XML Signature Wrapping Attack"): This is a common SAML attack where an attacker manipulates the XML structure to wrap a malicious element while preserving the signature, tricking the relying party into accepting a forged assertion. This attack exploits the way SAML parsers handle signed XML messages.

Option B ("XML External Entity Injection"): SAML messages are XML-based, making them susceptible to XXE (XML External Entity) attacks if the XML parser is misconfigured. An attacker can include external entities to access local files or make network requests, compromising the system.

Option C ("Assertion Replay Attack"): In this attack, an attacker intercepts a valid SAML assertion and reuses it to impersonate the user. If the assertion lacks proper replay protection (e.g., timestamps, nonces), the relying party may accept the replayed assertion as valid.

Option D ("All of the above"): Correct, as all three attacks (XML Signature Wrapping, XXE Injection, and Assertion Replay) are well-documented vulnerabilities in SAML implementations.

The correct answer is D, aligning with the CAP syllabus under "SAML Security" and "XML-Based Attacks."References: SecOps Group CAP Documents - "SAML Security Risks," "XML Vulnerabilities," and "OWASP SAML Security Cheat Sheet" sections.

Asymmetric key encryption (also known as public-key cryptography) uses a pair of keys: a public key for encryption and a private key for decryption (or vice versa for signing). Symmetric key encryption, on the other hand, uses the same key for both encryption and decryption. Let’s evaluate the options:

Option A ("AES"): AES (Advanced Encryption Standard) is a symmetric key encryption algorithm. It uses a single key (e.g., 128, 192, or 256 bits) for both encryption and decryption, making it a symmetric algorithm, not an asymmetric one.

Option B ("RSA"): RSA (Rivest-Shamir-Adleman) is an asymmetric key encryption algorithm. It uses a public key to encrypt data and a private key to decrypt it, making it a classic example of asymmetric cryptography.

Option C ("Diffie-Hellman"): Diffie-Hellman is an asymmetric key exchange algorithm. While it is primarily used for key exchange rather than direct encryption, it relies on asymmetric principles (public and private keys) to securely establish a shared secret, so it is considered part of asymmetric cryptography.

Option D ("DSA"): DSA (Digital Signature Algorithm) is an asymmetric algorithm used for digital signatures. It uses a pair of keys (public and private) for signing and verification, making it an asymmetric algorithm.

The correct answer is A, as AES is the only symmetric algorithm listed, aligning with the CAP syllabus under "Cryptography Fundamentals" and "Symmetric vs. Asymmetric Encryption."References: SecOps Group CAP Documents - "Cryptographic Algorithms," "Symmetric and Asymmetric Encryption," and "OWASP Cryptographic Storage Cheat Sheet" sections.

When multiple domain names (e.g.,www.ironman.com andwww.hulk.com ) resolve to the same IP address (e.g., 1.3.3.7), a web server hosting multiple applications on that IP must determine which application to serve. This is achieved using theHTTP "Host" header, which is part of the HTTP/1.1 protocol. The client (browser) includes the requested domain (e.g., Host: www.ironman.com) in the request, allowing the server to route the request to the appropriate virtual host or application configured for that domain. This is a standard practice in virtual hosting.

Option A ("The web server inspects the HTTP 'Host' header sent by the client"): Correct, as the Host header enables the server to distinguish between applications on the same IP.

Option B ("The web server inspects the cookies sent by the client"): Incorrect, as cookies are used for session management or personalization, not for identifying the requested application.

Option C ("The web server inspects the client's SSL certificate"): Incorrect, as SSL certificates are used for encryption and authentication, not for application routing (though they may include the domain name for validation).

Option D ("The web server uses a reverse DNS lookup of the client's IP address"): Incorrect, as reverse DNS lookup resolves an IP to a domain, which is irrelevant for the server determining the requested application.

The correct answer is A, aligning with the CAP syllabus under "Web Server Configuration" and "HTTP Protocol Security."References: SecOps Group CAP Documents - "HTTP Headers," "Virtual Hosting," and "OWASP Web Security Testing Guide" sections.

A docker-compose.yml file is a YAML-formatted configuration file used with Docker Compose, a tool for defining and running multi-container Docker applications. Its primary significance lies in orchestrating the deployment of Docker containers by specifying services (e.g., web server, database), networks (e.g., internal communication), and volumes (e.g., persistent storage). An exposed docker-compose.yml file poses a security risk because it may reveal sensitive configuration details, such as service names, ports, environment variables (e.g., database credentials), and network settings, which attackers could exploit to target the application.

Option A ("The docker-compose.yml file is a YAML file that contains the application source code"): Incorrect, as this file defines configuration and orchestration, not source code.

Option B ("The docker-compose.yml file is a YAML file that contains the server logs and user session information..."): Incorrect, as logs and session data are stored elsewhere (e.g., in container logs or databases), not in docker-compose.yml.

Option C ("The docker-compose.yml file is a YAML file that is used to define the services, networks, and volumes..."): Correct, as it accurately describes the file’s purpose and content, including configuration and dependencies, which are critical for Docker applications.

Option D ("The docker-compose.yml file is a YAML file that contains the configuration of load balancers and firewalls"): Incorrect, as it focuses only on load balancers and firewalls, which are specific components and not the primary focus of the file.

The correct answer is C, aligning with the CAP syllabus under "Container Security" and "Configuration Management."References: SecOps Group CAP Documents - "Docker Security," "Container Orchestration," and "OWASP Application Security Verification Standard (ASVS)" sections.

The code snippet is a Python script that takes user input for a filename, constructs a path by concatenating it with /var/www/html/files/, reads the file content, and prints it. The vulnerability arises because the filename variable is directly used in the path without sanitization or validation, allowing an attacker to manipulate it.

Path Traversal Vulnerability: An attacker can input a value like ../../etc/passwd to navigate outside the intended /var/www/html/files/ directory and access sensitive system files (e.g., /etc/passwd). Since the open() function will attempt to access the resulting path, this is a clear case of Path Traversal if the application runs with sufficient permissions.

Remote Code Execution (RCE): RCE would require the ability to execute arbitrary code, which is not directly possible here. The script only reads files, not executes them, unless the file contains executable code and the server interprets it (e.g., a PHP file on a web server),but this is not implied by the code alone.

Option A ("Path Traversal"): Correct, as the lack of input validation makes the code vulnerable to Path Traversal attacks.

Option B ("Remote Code Execution"): Incorrect, as the code does not execute the file content; it only reads it.

Option C ("Both A and B"): Incorrect, as RCE is not applicable here.

Option D ("None of the above"): Incorrect, as Path Traversal is a valid vulnerability.

The correct answer is A, aligning with the CAP syllabus under "Path Traversal Attacks" and "Input Validation."References: SecOps Group CAP Documents - "Path Traversal Vulnerabilities," "Input Sanitization," and "OWASP Top 10 (A05:2021 - Security Misconfiguration)" sections.

The HTTP request is a POST to /changepassword with a session cookie (JSESSIONID) and parameters new_password and confirm_password. Let’s evaluate each option:

Option A ("The change password feature does not validate the user"): The request includes a JSESSIONID cookie, which typically indicates that the user is authenticated via a session. There’s no evidence that user validation is absent, so this is not correct.

Option B ("The change password feature uses basic authorization"): Basic authorization would involve an Authorization: Basic header with a Base64-encoded username and password, which is not present here. The authentication appears to be session-based (via cookie), not basic auth, so this is incorrect.

Option C ("The change password feature is vulnerable to Cross-Site Request Forgery attack"): Cross-Site Request Forgery (CSRF) occurs when a malicious site tricks a user’s browser into making an unintended request to another site where the user is authenticated. This request lacks a CSRF token (e.g., a unique, unpredictable token in the request body or header) to verify the request’s legitimacy. The Sec-Fetch-Site: same-origin header indicates the request is currently from the same origin, but this is a browser feature, not a server-side CSRF protection. Without a CSRF token, the endpoint is vulnerable to CSRF, as an attacker could craft a malicious form on another site to submit this request on behalf of the user. This is the correct answer.

Option D ("All of the above"): Since A and B are incorrect, D cannot be correct.

The correct answer is C, aligning with the CAP syllabus under "Cross-Site Request Forgery (CSRF)" and "OWASP Top 10 (A08:2021 - Software and Data Integrity Failures)."References: SecOps Group CAP Documents - "CSRF Prevention," "Session Management," and "OWASP Secure Coding Practices" sections.

The HTTP response headers provide metadata about the server and its configuration. Let’s analyze each header and evaluate the statements:

Headers Breakdown:

Server: Microsoft-IIS/8.0: Indicates the web server is Microsoft Internet Information Services (IIS) version 8.0.

X-AspNet-Version: 2.0.50727: Indicates the application is using ASP.NET version 2.0.50727.

X-Powered-By: ASP.NET: Confirms the application framework is ASP.NET.

Other headers (e.g., Cache-Control, Content-Type, Expires) are standard and not directly relevant to the statements.

Option A ("The application is using an outdated server technology"): The Server: Microsoft-IIS/8.0 header indicates the server is running IIS 8.0, which was released in 2012 and is associated with Windows Server 2012. As of the current date (March 06, 2025), IIS 8.0 is outdated; Microsoft has released newer versions (e.g., IIS 10 with Windows Server 2016/2019). Additionally, mainstream support for Windows Server 2012 ended in October 2018, and extended support ended in October 2023, making IIS 8.0 unsupported and vulnerable to unpatched security issues. This statement is true.

Option B ("The application is disclosing the server version"): The Server: Microsoft-IIS/8.0 header explicitly discloses the server type (IIS) and version (8.0). Disclosing server version information is a security risk because attackers can use this to identify known vulnerabilities specific to that version (e.g., CVE exploits for IIS 8.0). Best practice is to suppress or obfuscate this header (e.g., Server: WebServer), so this statement is true.

Option C ("The application is disclosing the version of the framework used"): The X-AspNet-Version: 2.0.50727 header reveals the ASP.NET framework version (2.0.50727), which corresponds to .NET Framework 2.0, released in 2005. Disclosing the framework version is a security risk because attackers can target known vulnerabilities in that version (e.g., .NET Framework 2.0 is long unsupported; support ended in 2011). Best practice is to disable this header in the application configuration (e.g., in web.config for ASP.NET), so this statement is true.

Option D ("All of the above"): Since A (outdated server technology), B (disclosing server version), and C (disclosing framework version) are all true, this is the correct answer.

The correct answer is D, aligning with the CAP syllabus under "Information Disclosure" and "HTTP Header Security."References: SecOps Group CAP Documents - "Information Disclosure Prevention," "Server Hardening," and "OWASP Secure Headers Project" sections.

The robots.txt file is a text file placed in a website’s root directory to communicate with web crawlers (e.g., Googlebot) about which pages or resources should not be accessed or indexed. It uses directives like Disallow to specify restricted areas (e.g., Disallow: /admin/). However, robots.txt is not a security mechanism; it is only a request to crawlers, and malicious bots or users can ignore it.

Option A ("Developers must not list any sensitive files and directories in this file"): Correct. Listing sensitive files or directories (e.g., Disallow: /secret/) in robots.txt can inadvertently expose their existence to attackers, who can then attempt to access them directly. The best practice is to avoid mentioning sensitive paths and rely on proper access controls (e.g., authentication, authorization) instead.

Option B ("Developers must list all sensitive files and directories in this file to secure them"): Incorrect. Listing sensitive paths in robots.txt does not secure them; it only informs crawlers to avoid them, and it can serve as a roadmap for attackers.

Option C ("Both A and B"): Incorrect, as A and B are contradictory; B is false.

Option D ("None of the above"): Incorrect, as A is true.

The correct answer is A, aligning with the CAP syllabus under "Web Crawler Security" and "Information Disclosure Prevention."References: SecOps Group CAP Documents - "robots.txt Usage," "Information Exposure," and "OWASP Web Security Testing Guide" sections.

The Same-Origin Policy (SOP) is a fundamental security mechanism in web browsers that restricts how a document or script loaded from one origin can interact with resources from another origin. An origin is defined by the combination ofprotocol,host, andport. Two pages have the same origin if their protocol (e.g., http://), host (e.g., www.example.com ), and port (default is 80 for HTTP) match exactly. The given URL is http://www.example.com/dir/page2.html, which uses HTTP, host www.example.com, and the default port 80.

Option 1 ("http://www.example.com/dir/other.html"): Matches the protocol (http), host (www.example.com ), and port (default 80), so it is in the same origin.

Option 2 ("http://www.example.com:81/dir/other.html"): Differs in port (81 vs. default 80), so it is a different origin.

Option 3 ("http://www.example.com/dir/other.html"): Identical to Option 1, matching protocol, host, and port, so it is in the same origin. However, since it’s a duplicate of Option 1 in the list, it doesn’t add a new page.

Option 4 ("http://en.example.com/dir/other.html"): Differs in host (en.example.com vs.www.example.com ), so it is a different origin.

Since the question asks which pages are in the same origin, and only Option 1 (and its duplicate Option 3) matches, the correct answer is A ("1 Only"), considering unique pages. The CAP syllabus covers SOP under "Client-Side Security" and "Cross-Origin Resource Sharing (CORS)."References: SecOps Group CAP Documents - "Same-Origin Policy," "Browser Security Models," and "OWASP Client-Side Security" sections.

The scenario describes a vulnerability where a user can manipulate the order_id parameter in theURL (e.g., https://example.com/?order_id=53870) to access other users’ order details, indicating a lack of proper access control. This is a classic case of an Insecure Direct Object Reference (IDOR)attack. IDOR occurs when an application exposes a reference to an internal object (e.g., an order ID) that can be manipulated by an unauthorized user to access resources they should not have access to, without validating the user’s permissions.

Option A ("Insecure Direct Object Reference"): Correct, as the ability to change order_id to view arbitrary orders fits the definition of IDOR.

Option B ("Session Poisoning"): Incorrect, as session poisoning involves corrupting or altering a user’s session data, which is not indicated here.

Option C ("Session Riding OR Cross-Site Request Forgery"): Incorrect, as CSRF involves tricking a user into submitting a request (e.g., via a malicious form), not manipulating a URL parameter directly.

Option D ("Server-Side Request Forgery"): Incorrect, as SSRF involves tricking the server into making unauthorized requests to internal or external resources, which is not the case here.

The correct answer is A, aligning with the CAP syllabus under "Insecure Direct Object References (IDOR)" and "OWASP Top 10 (A04:2021 - Insecure Design)."References: SecOps Group CAP Documents - "IDOR Vulnerabilities," "Access Control," and "OWASP Testing Guide" sections.