1. In the Ticketmaster / Magecart / Inbenta incident (2018), how did the attackers steal payment card data from Ticketmaster customers?
Correct. Attackers compromised Inbenta’s CDN and injected a Magecart card-skimming payload into the JavaScript file Ticketmaster loaded on its checkout pages. The skimmer ran in users’ browsers and exfiltrated card data before it ever reached Ticketmaster’s API. Ticketmaster’s own systems were never directly compromised.
The attack didn’t target Ticketmaster’s API or database directly. Attackers compromised Inbenta’s CDN — a third-party chatbot vendor Ticketmaster trusted — and modified the JavaScript file Ticketmaster loaded on payment pages. The skimmer ran in customers’ browsers, intercepting card data before it reached any server.
2. An API consumes a third-party address validation service. The service returns the canonical address as a string. The API inserts this string into a SQL query using string concatenation rather than parameterized queries. A compromised third-party returns SQL injection in the address field. What API10 mitigation would have prevented this?
Correct. MIT 02 requires using parameterized queries for all SQL statements regardless of where the data came from. Parameterization separates SQL code from data, making injection impossible even if the data contains SQL injection payloads. The source of the data (third-party vs. user) is irrelevant — the control belongs at the point of SQL use.
HTTPS provides transport security — it ensures the response came from the expected server without modification in transit. But if the third-party server itself is compromised, HTTPS doesn’t help. The fix is parameterized queries on all SQL statements, applied at the point of use regardless of data source.
3. Which HTML attribute on a script tag allows a browser to verify the integrity of a third-party CDN script before executing it?
Correct. The integrity attribute (part of the Subresource Integrity / SRI standard) specifies a cryptographic hash of the expected script content. The browser hashes the downloaded file and compares it to the expected value. If they don’t match — because the file was tampered with — the browser refuses to execute the script. This is the direct technical defense against Magecart-style CDN compromise.
The integrity attribute (Subresource Integrity / SRI) is what allows browsers to verify third-party script content before execution. It contains a cryptographic hash of the expected file. If the CDN file is modified, the hash won’t match and the browser blocks execution. This would have prevented the Ticketmaster incident.
4. An API follows all redirects returned by a trusted OAuth identity provider. An attacker compromises a subdomain of the identity provider and returns a redirect to http://169.254.169.254/latest/meta-data/. The API follows the redirect and retrieves IAM credentials. Which mitigation addresses this?
Correct. MIT 03 requires validating the destination of all redirects — including those from trusted third parties — against an allowlist that blocks private IP ranges. The source of the redirect doesn’t determine whether the destination is safe. SSRF via redirect works precisely because the consuming API trusted the redirect source and skipped destination validation.
SSL certificate verification only confirms the redirect came from the expected domain — but if that domain (or its subdomain) is compromised or taken over, certificate verification passes. The fix is to validate where the redirect goes: check the destination URL against an allowlist that blocks private IP ranges, cloud metadata endpoints, and internal addresses.
5. What is the fundamental difference between input validation applied to user data vs. third-party API responses in most API implementations — and what does OWASP API10 say about this?
Correct. API10’s core finding is that developers apply strict validation to user input but treat third-party API responses as inherently trustworthy — skipping the same controls. OWASP says this asymmetry is the vulnerability: security controls (parameterization, escaping, URL validation) should be applied based on how the data is used, not based on where it came from.
In practice, most APIs apply much stricter validation to user input than to third-party responses. API10 identifies this as the problem — not the solution. The correct approach: apply the same validation, parameterization, and escaping to all external data regardless of source, based on how the data will be used, not who sent it.