The authoritative source for the definition, vulnerability patterns (trusting third-party responses without validation), example attack scenarios (SQL injection via third-party response, SSRF via redirect, XSS via profile data), and prevention guidance in this module. CWE references: CWE-285 (Improper Authorization), CWE-601 (URL Redirection to Untrusted Site), CWE-918 (Server-Side Request Forgery). This course is an independent study companion — not affiliated with or endorsed by OWASP.

Ticketmaster UK integrated Inbenta’s customer support chatbot widget on its payment pages. Attackers attributed to Magecart Group 9 by RiskIQ compromised Inbenta’s CDN and modified the JavaScript file served to Ticketmaster to include a card-skimming payload. The skimmer ran undetected from approximately February to June 2018. Monzo Bank identified the breach through fraud pattern analysis. Approximately 40,000 UK customers and up to 9.4 million European customers were affected. Ticketmaster was fined £1.25 million by the UK ICO in November 2020. Inbenta published a blog post on June 28, 2018 stating the attack targeted a JavaScript snippet customized for Ticketmaster that was not intended for use on payment pages. Referenced in slides 1, 10, 11, 23, 26. Primary sources: UK ICO enforcement notice (November 2020), Inbenta blog post (June 28, 2018), RiskIQ Magecart research (2018–2019).

Log4Shell is a critical vulnerability (CVSS 10.0) in Apache Log4j 2 where the library evaluates JNDI lookup expressions (${jndi:ldap://...}) found in log messages, enabling server-side DNS queries and remote class loading that can result in remote code execution. Publicly disclosed December 9, 2021. Mass exploitation began within 24 hours. CISA ordered all U.S. federal agencies to patch within one week. The API10 relevance: many APIs consumed third-party API responses (geolocation enrichment, user-agent parsing, analytics data) and logged them without sanitization. An attacker who could influence what a third-party returned — or who compromised a third-party service — could deliver a Log4Shell payload through the trusted data path, bypassing input validation applied only to user-submitted values. Fixed in Log4j 2.17.1 (JNDI disabled by default). Referenced in slides 5, 13. Primary sources: CVE-2021-44228 NVD entry, Apache Log4j security advisory, CISA Emergency Directive ED 21-04.

The W3C Subresource Integrity specification defines the integrity attribute for <script> and <link> tags. The attribute value contains a cryptographic hash (SHA-256, SHA-384, or SHA-512) of the expected file content. Browsers that support SRI verify the hash before executing the resource; a mismatch causes the resource to be blocked. SRI is broadly supported in all major browsers. Directly addresses Magecart-style CDN compromise by making any modification to a third-party script detectable and blockable. Relevant to MIT 05 (slide 23). MDN documentation provides implementation guidance for common frameworks.

RiskIQ published extensive research on the Magecart threat group(s) — a loose collective of criminal groups that specialize in card skimming via compromised third-party JavaScript on e-commerce sites. Between 2015 and 2020, Magecart is estimated to have affected over 100 organizations including British Airways (ICO fine: £20M, later reduced to £20M then £20M), Ticketmaster UK, Newegg, and thousands of smaller sites through compromised Magento plugins. The research catalogued the technical methods: CDN compromise, third-party script injection, subdomain hijacking to impersonate legitimate CDN domains, and formjacking (injecting skimmers into payment form submit handlers). Directly informs slides 8, 10, 11.

OWASP’s Third Party JavaScript Management Cheat Sheet covers: risks of loading third-party scripts, Subresource Integrity implementation, Content Security Policy for script-src restrictions, sandbox iframes for isolating third-party widget content, and monitoring for third-party script changes. Directly informs MIT 04 (vendor due diligence), MIT 05 (SRI), and MIT 07 (isolation) in slides 22, 23, and 25.

Content Security Policy is an HTTP response header that restricts which resources (scripts, styles, images, frames) a page can load and from which origins. The script-src directive combined with SRI hashes provides defense-in-depth against third-party script compromise: CSP restricts which CDN origins can serve scripts, and SRI verifies the hash of what those origins serve. CSP violation reports (via the report-uri or report-to directive) alert on blocked resources — providing detection for compromise attempts even when the attack is blocked. Relevant to MIT 05 (slide 23).

PortSwigger’s labs on supply chain and third-party trust attacks include: DOM-based XSS via third-party library, prototype pollution via CDN libraries, and client-side template injection. These labs provide hands-on practice with the attack patterns that underlie API10’s client-side threat vector.

SLSA is a security framework for software supply chain integrity. It defines levels of assurance for how artifacts (code, builds, packages) were produced and protected from tampering. While primarily focused on the build and distribution pipeline rather than API consumption, SLSA provides the framework for thinking about third-party trust in the broader supply chain — directly relevant to the vendor due diligence (MIT 04) and isolation (MIT 07) mitigations in this module.