Web App API Attacks practice questions

SQL Injection

Why it fails: While the response contains information that facilitates SQL injection, the presence of the debug data itself is classified as Excessive Data Exposure. SQL injection is the exploitation of the input fields, whereas the exhibit shows the resulting information leak caused by poor API design.

Improper Asset Management

Why it fails: Improper Asset Management relates to the use of obsolete or unpatched API versions. The exhibit shows a data exposure issue rather than a versioning or lifecycle management problem. The issue is focused on what data is returned, not which version of the API is serving it.

Broken Object Level Authorization

Why it fails: Broken Object Level Authorization would manifest if the user was able to access data belonging to another user. The exhibit shows unnecessary information being returned for a successful request, which is an information disclosure issue, not an authorization failure regarding the object ownership.

Remote code execution via deserialization

Why it fails: Deserialization attacks occur when untrusted data is deserialized into objects, often leading to code execution. The scenario describes reflection of a parameter into a JSON response, not deserialization of malicious objects. Thus, this attack type is not directly enabled.

Cross-site scripting (XSS) via JSON hijacking

Why it fails: JSON hijacking typically involves exploiting array constructors or overriding object prototypes to steal data, not reflecting a callback parameter. The described behavior—reflecting a parameter into JSON—is more aligned with JSONP injection, which can lead to XSS if the response is interpreted as script. However, the most direct attack is JSONP injection, not classic JSON hijacking.

Server-side request forgery (SSRF) through callback URLs

Why it fails: SSRF involves the server making requests to attacker-controlled or internal URLs. Here, the callback parameter is reflected in the response, not used to make server-side requests. Therefore, SSRF is not enabled by this behavior; the risk is client-side script execution.

Cross-Site Request Forgery

Why it fails: Cross-Site Request Forgery forces authenticated users to execute unintended state-changing actions under their current session. The described scenario involves direct parameter manipulation to query unauthorized resources rather than forging requests via third-party malicious websites leveraging browser cookie persistence mechanisms.

Server-Side Request Forgery

Why it fails: Server-Side Request Forgery occurs when a vulnerable application fetches a remote resource supplied by the user without adequate validation. Modifying a numerical user identifier in a RESTful API path is an access control failure, not an arbitrary outbound network request vulnerability originating from the backend server.

Mass Assignment

Why it fails: Mass Assignment happens when client-supplied inputs are automatically bound to internal object properties, potentially allowing privilege escalation or unwanted attribute modification. Manipulating a URL path parameter to access sequential resource records represents an authorization flaw rather than unintended data binding during object creation.

Broken User Authentication

Why it fails: Broken authentication weaknesses involve flaws in credential management, session handling, or password recovery mechanisms that allow attackers to compromise user accounts. Injecting hidden parameters into a valid registration request is an input binding issue rather than an authentication credential bypass vulnerability.

Server-Side Request Forgery

Why it fails: Server-Side Request Forgery allows an attacker to manipulate the application server into issuing unintended network requests to internal or external systems. Modifying object properties within a JSON payload sent directly to an API endpoint is completely unrelated to outbound server-side HTTP networking.

Cross-Site Scripting

Why it fails: Cross-Site Scripting allows malicious scripts to execute within a victim's browser context due to improper output encoding or input sanitization. Injecting JSON attributes to manipulate server-side data models represents an API data binding flaw rather than client-side script injection.

Broken Authentication

Why it fails: Broken authentication involves issues with session management or credential validation mechanisms. While the attacker accesses data, the failure is specifically related to object-level authorization rather than the mechanism used to verify the identity of the user requesting the resource initially.

Cross-Site Scripting

Why it fails: Cross-Site Scripting involves injecting malicious scripts into web pages viewed by other users. The scenario describes data access manipulation rather than the injection of client-side code execution. IDOR focuses on the backend resource access control logic rather than the presentation layer execution.

Insufficient Logging and Monitoring

Why it fails: Insufficient logging refers to the inability of the system to record and alert on suspicious activities. While logging might be lacking, the primary vulnerability that allowed the data access is the lack of authorization checks on the object reference itself, not the logging policy.

Always sanitize input for SQL injection patterns

Why it fails: Sanitization is critical for preventing SQL injection but does not mitigate Mass Assignment. Mass Assignment is an architectural flaw in how data is mapped to objects, whereas SQL injection relates to the execution of malicious queries within the database layer.

Increase the complexity of the API authentication token

Why it fails: Authentication token complexity improves resistance against brute-force or credential theft attacks. It has no bearing on Mass Assignment, which typically occurs after a user has been successfully authenticated and is interacting with an endpoint that trusts user-provided data fields too implicitly.

Disable all write operations on public API endpoints

Why it fails: Disabling write operations would make the API non-functional for intended business purposes. Mitigation must focus on secure coding practices, such as input validation and DTO usage, rather than restricting core functionality, which would violate the availability requirements of the business service.

Denial of Service

Why it fails: Denial of Service aims to overwhelm or crash the API service. Manipulating redirect parameters is a logic-based exploit focused on authentication bypass or token theft, not service availability. The attack objective is to gain unauthorized access, not to degrade the quality of the service.

Cross-Site Request Forgery

Why it fails: CSRF involves tricking a user's browser into performing actions on a different site. While related to authentication, the specific manipulation of OAuth redirect URIs is designed for intercepting authorization codes during the OAuth handshake process, which is fundamentally different from triggering unauthorized state-changing actions via browsers.

Server-Side Request Forgery

Why it fails: SSRF occurs when an attacker forces the server to make requests to unintended locations. Redirect URI manipulation happens on the client-side authorization flow and does not force the backend server to perform requests against internal infrastructure; it merely directs the user's browser agent to a malicious destination.

Hardcoded database credentials for internal services

Why it fails: Hardcoding credentials is a dangerous practice that violates fundamental security principles. Documentation should never contain sensitive secrets; instead, it should reference secure secret management systems like Vault. Including credentials in documentation introduces a high risk of compromise if the documentation itself is accessed by unauthorized actors.

Customer personal identifiable information (PII) logs

Why it fails: PII should not be stored in documentation or incident logs due to privacy regulations like GDPR. Including PII in documentation creates unnecessary liability and security risks. Incident response documentation should focus on metadata, behavioral patterns, and structural anomalies, never raw sensitive user data or customer information.

The token expires in less than 60 seconds

Why it fails: Token expiration is a standard security control to limit the window of opportunity for intercepted tokens. It is unrelated to the algorithm field validation. A short expiration does not prevent an attacker from modifying the header to 'none' if the backend fails to validate signatures.

The token uses RS256 instead of HS256

Why it fails: RS256 is an asymmetric algorithm and is generally considered more secure than symmetric HS256. Using RS256 does not inherently indicate a vulnerability. The vulnerability lies in the improper handling of the algorithm header, regardless of whether asymmetric or symmetric keys are used for signing.

The secret key is stored in an environment variable

Why it fails: Storing secret keys in environment variables is a standard security practice, provided those variables are protected. This does not relate to the JWT 'alg' field vulnerability, which is an implementation flaw in how the API processes the incoming token's signature requirements and the algorithm specified.

Enforcing HTTPS for all traffic

Why it fails: HTTPS provides confidentiality and integrity for data in transit. While essential, it does not prevent a client from sending many legitimate but resource-intensive requests that consume backend server resources, leading to a Denial of Service. HTTPS protects the transport, not the server's resource availability.

Using JWTs for authentication

Why it fails: JWTs are an authentication mechanism. While they verify the identity of the requester, they do not restrict how often an authenticated user can hit an endpoint. An authenticated attacker can still trigger a DoS by repeatedly calling an expensive function, so JWTs do not prevent DoS.

Disabling CORS headers

Why it fails: CORS controls browser-side access to APIs across domains. It is not an anti-DoS mechanism. An attacker using a command-line tool like curl or a custom script will ignore CORS headers entirely, rendering this control ineffective against API-based DoS attacks originating from non-browser environments.

Broken Object Level Authorization

Why it fails: BOLA occurs when an attacker accesses another user's data. Here, the attacker is modifying the request parameters for a legitimate transaction, not accessing another object. The issue is about the manipulation of the transaction price through the API, not unauthorized access to a different user's resource.

Command Injection

Why it fails: Command injection involves executing arbitrary system commands on the server. The exhibit shows JSON parameter modification. There is no evidence of shell characters or system calls being injected into the input; rather, it is a business logic flaw where the application trusts user input too much.

Cross-Site Scripting

Why it fails: XSS is a client-side vulnerability where scripts are injected into web pages. This scenario involves a server-side API processing logic error regarding data binding. No scripts are being executed, and the context is purely back-end API data processing and state modification based on user input.

They are easily cracked using brute-force tools

Why it fails: API keys are typically high-entropy random strings, making them resistant to brute-force attacks. The primary risk is not that they can be guessed, but that they can be stolen or leaked from insecure storage locations, leading to unauthorized persistent access to the API services.

They cannot be used over HTTPS connections

Why it fails: API keys are frequently sent over HTTPS, which protects them from network sniffing. The limitation is not the protocol, but the fact that they are static secrets. If the key is leaked, the channel encryption doesn't help because the attacker possesses the valid secret key itself.

They are incompatible with RESTful architecture

Why it fails: API keys are perfectly compatible with RESTful services and are widely used for simple authentication. While less secure than OAuth for complex requirements, their use does not violate the REST paradigm. The issue with keys is the security risk of long-lived secrets, not architectural compatibility.

Failure to encrypt sensitive API parameters

Why it fails: Encryption relates to confidentiality during transit. BOLA is an authorization flaw, not an encryption flaw. Even if the traffic is encrypted with TLS, if the backend server doesn't check if user A has permission to access user B's object ID, BOLA still exists.

Inability to verify the requester's identity

Why it fails: That is the definition of Broken Authentication. BOLA assumes the user is already authenticated but is accessing data that they should not be authorized to view or modify. The identity is known, but the authorization check against the specific resource is missing or incorrect.

Excessive use of third-party API libraries

Why it fails: Using third-party libraries is a supply chain risk, not an authorization risk. While libraries might contain vulnerabilities, BOLA is an architectural logic failure regarding how the API handles data access permissions for individual resources. It is independent of the third-party components used by the application.

Use a public proxy for all outgoing requests

Why it fails: Using a public proxy does not fix SSRF. If the proxy itself is not configured to filter requests, the attacker can still use it to perform malicious actions. Furthermore, it adds unnecessary complexity and potentially exposes traffic to the proxy provider without providing any actual security benefits.

Store all API secrets in the URL parameters

Why it fails: Storing secrets in URL parameters is an extremely insecure practice that facilitates credential leakage through logs, browser history, and proxy servers. This practice is entirely unrelated to SSRF mitigation and actually introduces significant new security risks related to information disclosure and credential theft.

Broken Authentication due to weak session token generation algorithms allowing session hijacking across user accounts.

Why it fails: Weak token generation allows attackers to forge active session identifiers, whereas this scenario involves a fully authenticated user simply swapping integer resource identifiers within the URI path to access unauthorized data objects belonging to other users directly.

Mass Assignment vulnerability caused by automatically binding incoming HTTP request parameters to internal backend database object properties.

Why it fails: Mass Assignment binds request body fields to object properties, whereas this attack manipulates the URI path identifier to reach another user's record, which is Broken Object Level Authorization. Mass Assignment would be correct if extra JSON fields altered unintended attributes on the caller's own object.

Improper Assets Management stemming from exposed documentation and forgotten non-production API endpoints lacking proper security controls.

Why it fails: Improper Assets Management concerns undocumented, deprecated or non-production endpoints left exposed, not an authorised endpoint missing object-level checks. Here the live /api/v1/users/{id}/settings route lacks ownership validation, which is Broken Object Level Authorization; assets management would apply to forgotten staging APIs.

Cross-Site Request Forgery

Why it fails: Cross-Site Request Forgery tricks a victim into executing unwanted actions on a trusted application where they are currently authenticated. It relies on session cookies rather than the direct manipulation of object identifiers within REST API query parameters or paths.

Server-Side Request Forgery

Why it fails: Server-Side Request Forgery involves tricking a server-side application into making HTTP requests to an arbitrary unintended domain or internal resource. It does not describe the direct parameter tampering used to access other users' database records.

Mass Assignment Vulnerability

Why it fails: Mass assignment occurs when an API binds client-supplied fields directly to object properties, allowing attackers to set attributes they should not control. Here the attacker alters an object identifier in the URL to reach another tenant's record, which is broken object level authorisation, not property-level binding.

Broken Function Level Authorization

Why it fails: Broken function level authorisation concerns access to privileged operations or endpoints, such as reaching an admin-only action. This attacker stayed within the same users endpoint and altered the object identifier, so the flaw is object-level access control, not function-level. Function-level checks would matter if the path itself changed to an admin route.

Cross-Site Request Forgery

Why it fails: CSRF tricks a victim's authenticated browser into issuing unintended state-changing requests, relying on ambient session credentials. Here the attacker sent their own authenticated requests and simply changed an object identifier, which is an object-level authorisation failure, not request forgery. CSRF would fit a forged transfer or password change.

Server-Side Request Forgery

Why it fails: This flaw allows an attacker to induce the backend server to make HTTP requests to an arbitrary unintended external or internal destination, which is unrelated to modifying sequential user resource identifiers in an API path.

Attackers can directly execute arbitrary code on the GraphQL server through introspection queries.

Why it fails: Introspection only returns metadata about the schema; it does not execute code or allow arbitrary command execution. While exposed introspection aids reconnaissance, it does not by itself grant code execution. The attacker would need a separate vulnerability, such as a deserialization flaw or a vulnerable resolver, to achieve that. Therefore, this option overstates the impact and is not the most significant consequence of the finding.

Attackers can bypass authentication by sending a specially crafted introspection query that returns valid session tokens.

Why it fails: Introspection queries do not return session tokens or authentication credentials; they only describe the schema. Authentication bypass requires a flaw in the authentication mechanism itself, such as weak token validation or misconfigured middleware. Introspection does not interact with the authentication layer in that way. Thus, this option misrepresents the purpose and output of introspection.

Attackers can cause a denial of service by sending an introspection query that recursively expands the schema indefinitely.

Why it fails: While introspection can be resource-intensive, it does not recursively expand indefinitely by design; the schema is finite. A denial of service via introspection is possible but requires overwhelming the server with complex queries, not a single recursive query. The most direct impact of exposed introspection is information disclosure, not DoS. This option mischaracterizes the primary risk.

Insecure Direct Object Reference (IDOR)

Why it fails: IDOR involves accessing objects by manipulating identifiers, such as changing a user ID in a URL. In this case, the attacker is not manipulating an object identifier but supplying a URL to an internal service. The server's action of fetching that URL is the core issue. IDOR does not involve server-side requests to arbitrary URLs. Hence, this option is not applicable.

Cross-Site Request Forgery (CSRF)

Why it fails: CSRF involves tricking a victim's browser into sending an authenticated request to a vulnerable application. Here, the attacker directly supplies a URL to the API, and the server fetches it; there is no victim browser or forged request from a trusted user. CSRF does not involve server-side fetching of remote resources. Therefore, this option is incorrect for the described scenario.

XML External Entity (XXE) injection

Why it fails: XXE occurs when an application parses XML input containing external entities, leading to file disclosure or SSRF. However, the scenario describes a JSON or form parameter specifying a URL, not XML parsing. There is no mention of XML input. XXE is a different vulnerability class that requires XML processing. Thus, this option does not fit the observed behavior.

Cross-site scripting (XSS) in API responses

Why it fails: XSS involves injecting client-side scripts that execute in a victim's browser, not probing server-side API paths for version discovery. The logs show no injected script payloads or browser interactions; they show direct requests to different API paths. Therefore, this pattern does not indicate XSS.

Server-side request forgery (SSRF) via API parameters

Why it fails: SSRF occurs when an API fetches a user-supplied URL, causing the server to make requests to internal or external systems. Here, the attacker is directly requesting API endpoints, not manipulating a parameter to make the server issue requests. No SSRF indicators such as URL parameters are present.

JWT algorithm confusion attack

Why it fails: JWT algorithm confusion involves manipulating the token's header to force a weaker verification algorithm, typically after obtaining a valid token. The described log activity shows unauthenticated probing of API paths, not token manipulation. Thus, this technique is not supported by the evidence.