CCNA Web App API Attacks Questions

Introspection reveals types, fields, arguments, and mutations, giving attackers a complete blueprint of the API. This enables precise targeting of sensitive operations, such as user data retrieval or privilege escalation via mutations. The exposure significantly reduces the effort needed for further attacks, making it a serious information disclosure issue. This is the primary risk when introspection is left enabled without authentication.

The API allows the client to overwrite the 'final_price' attribute, which should be a server-calculated value. This is a classic Mass Assignment flaw where the application layer blindly binds user-supplied JSON properties directly to the backend object model, allowing the attacker to alter critical business logic.

SSRF occurs when an application fetches a remote resource without validating the user-supplied URL, allowing attackers to make requests to internal systems. In this scenario, the attacker supplied a URL to the cloud metadata service, and the server fetched it, exposing credentials. This is a classic SSRF exploitation. The other options do not match the behavior of the server making a request to an attacker-controlled or internal URL.

BOLA occurs when an application relies on user-provided input to identify an object but fails to verify that the authenticated user actually has the permissions to access that specific object. This enables attackers to interact with resources belonging to other users simply by changing identifiers.

Mass assignment arises when automated object mapping features bind HTTP request parameters directly to internal data structure properties. Attackers exploit this by appending sensitive fields like role or status flags to registration or profile update payloads to gain unauthorized administrative privileges.

If the 'alg' header is set to 'none', the token is effectively unsigned. If the API implementation is vulnerable, it will trust the payload without requiring a cryptographic signature, allowing attackers to forge arbitrary tokens by modifying the payload content to elevate privileges or impersonate other users.

API keys are long-lived static secrets that often appear in source code, configuration files, or logs. Since they typically grant permanent access until revoked, their leakage represents a high risk, as attackers can use the stolen keys indefinitely without needing to re-authenticate or renew session tokens.

Defining an explicit allow-list of fields that the API is permitted to bind ensures that unexpected or sensitive fields provided by the client are ignored. This technique creates a secure boundary between external input and internal object properties, effectively neutralizing Mass Assignment risks.

Modifying object identifiers to reach other tenants' records is Broken Object Level Authorization: the API authenticates the caller but never verifies that the caller owns the requested object. Authorization is enforced per object, not per endpoint, which is exactly the flaw described.

The attacker systematically probes multiple API version prefixes and internal paths to discover which versions are live and may lack security controls. The single successful response reveals a valid version, making version enumeration the technique in use. This is a common precursor to exploiting deprecated or unpatched API versions.

Rate limiting restricts the frequency of requests from a specific source, preventing attackers from overloading the API with resource-intensive requests. This ensures that system resources are distributed fairly and prevents any single source from exhausting the server's capacity, which is the primary goal of API DoS prevention.

Detailed database errors on quote injection strongly suggest SQL injection, while the 500 error on malformed nested JSON indicates insufficient input validation. Together, they point to injection flaws where untrusted input reaches interpreters or parsers. This is consistent with the analyst's observations and is a high-severity finding.

The payloads ' OR 1=1 --' and 'UNION SELECT ...' are classic SQL injection attempts. They aim to alter the logic of SQL queries to bypass authentication or extract data. The login endpoint is a common target for such attacks. This matches the observed behavior, making SQL injection the correct classification. The other options describe different attack types that do not involve SQL syntax.

By modifying the redirect_uri to an attacker-controlled endpoint, the authorization server redirects the user's browser with the authorization code sent to the attacker. The attacker then exchanges this code for a valid access token, bypassing standard authentication flows and gaining full access to the victim's account.

The query chains relationship fields arbitrarily deep, so the server resolves a combinatorial explosion of related records in one request, producing a multi-megabyte response and heavy database joins. This is the GraphQL-specific resource exhaustion pattern that arises when depth, complexity, and pagination limits are absent. Authentication was valid, so the abuse is in query structure rather than identity, matching the observed database spike.

Allow-lists ensure the API server only makes requests to trusted, predefined domains. By rejecting requests to unexpected or internal endpoints, the risk of the server being used as a proxy to attack internal infrastructure is significantly reduced, effectively mitigating the primary target of most SSRF exploits.

Recursive entity definitions cause parsers to expand references exponentially, the classic billion-laughs pattern that consumes memory and CPU. Testing this against the catalog import shows whether the parser enforces entity expansion limits or disables internal entity resolution. It is XML-specific and directly relevant to an upload endpoint that must safely handle documents from external suppliers.

Because the gateway routes on the attacker-controllable X-Tenant-Id header while authorization relies only on the bearer token, an authenticated partner can name any tenant and receive its documents. The tenant boundary should be derived from a verified token claim or server-side session, never from a header the caller can set. This is a broken authorization design flaw rather than a token forgery or injection issue.

The endpoint returns sensitive fields that the client query did not request, and no field-level authorization prevents them from being serialized. In GraphQL, the server executes resolvers for fields selected by the query, but if a resolver or schema design includes sensitive properties in the returned object, the response can expose them. The handler should treat this as excessive data exposure and review resolver authorization and field visibility.

APIs frequently expose endpoints that handle object identifiers, creating a wide attack surface for object-level access control flaws. Without proper authorization validation verifying whether the logged-in user owns the requested object ID, attackers easily iterate through identifiers to read or modify private data records.

The API trusted the client-supplied identifier without verifying that the authenticated user owned or was authorised for that record. Changing /users/104 to /users/1 returned another user's administrative data, which is the defining pattern of Insecure Direct Object Reference.

Missing authorization checks on resource identifiers allow authenticated users to access or modify objects by altering parameters like user IDs in the URI. This represents a classic failure of object-level access controls within modern RESTful API architectures.

OpenAPI documents provide a ground truth of the API's intended design, including expected input formats, authentication methods, and endpoint definitions. Responders use this to detect anomalies by comparing actual request structures against the documented schema to identify malicious variations or unexpected inputs.

The API authenticated the caller but never verified that the caller owned account 8842 before returning its transactions, which is the defining characteristic of broken object level authorization. Access control must be enforced per object on every request using the authenticated identity, not merely by requiring a valid session. This is why a legitimate user can read another customer's financial records simply by changing the identifier.

IDOR occurs when an application provides direct access to objects based on user-supplied input. By manipulating the ID parameter, the attacker accesses unauthorized data records. APIs are particularly susceptible to this when they rely on sequential IDs for object retrieval without verifying user permissions.

GraphQL allows clients to request nested fields, and without depth limiting, an attacker can craft a query with many levels of nesting. This can cause exponential resource consumption as the server resolves each level, leading to denial of service. This is known as a query depth attack.

If the server fetches the key from a location specified by the 'kid' header, an attacker can point it to a malicious server hosting a key they control, or to a local file. This allows the attacker to sign tokens with a key the server will trust, bypassing authentication.

The payload's pathological depth targets the deserializer itself, driving recursive object graph construction until CPU and memory are consumed and the worker dies. Because the application binds arbitrary JSON straight into internal model objects with no depth or size limit, an attacker fully controls the structure parsed, which is exactly the unsafe deserialization condition that turns a normal data-parsing routine into a denial-of-service primitive.