Loading
Every factual claim in this course traces to something here, grouped by the module it serves. Each page was opened on 3 September 2026. This material rots faster than anything else on the shelf — browser support figures, spec item names and compliance documents all move, and one source below is a previous edition kept deliberately so the change is visible. If you find a source that contradicts a lesson, that is worth raising with your teaching agent: the lesson should change, or it should say why it disagrees.
Why model output is untrusted input, what a renderer hands over, and the boundary between a surface that displays and one that acts.
WhyThe edition trap, and it is a bad one: the obvious URL genai.owasp.org/llm-top-10/ still serves the 2025 list and ranks first in search. The 2026 edition has no per-entry web pages yet — its text lives only as Markdown in the project repository, which is why the entries below link to GitHub. Eight of the ten items moved between editions, so always state which edition you are quoting.
WhyThe definition explicitly includes retrieved content, tool output, image, audio and video content, intermediate reasoning and persistent memory — not just what a user types. Source for the verdict this course refuses to soften: “no reliable prevention mechanism exists today”, and “Defense is therefore architectural rather than interceptive.” Primary source for the untrusted-input lesson.
WhyKept for one sentence: the 2025 entry says it is “unclear if there are fool-proof methods of prevention.” The 2026 entry says none exists. The direction of that revision — the field converging on admitting there is no solution rather than finding one — is itself worth carrying into a meeting.
WhyMoved up from sixth to third in 2026. The mitigations repeat one word — limit tools, functions and permissions to the minimum necessary — and then land the fourth one on a screen somebody has to build: “Use human-in-the-loop control to require a human to approve high-impact actions before they are taken.” Source material for the action-trigger lesson. Also cited in the raising-it-properly module’s non-blocking lesson as the shape a proposal should copy: each mitigation only narrows what a failure reaches and none claims to solve excessive agency, which is exactly the property a non-blocking mitigation needs.
WhyFell from fifth to tenth, the furthest fall on the 2026 list — a reweighting toward agentic risk, not a retraction, and the entry actually gained front-end-specific guidance while losing rank. It was “Insecure Output Handling” in the 2023/24 edition, so a search may return the old name. Source for the two client-renderer sentences: prevent model output from triggering automatic outbound requests, and disable auto-rendering of Markdown images, link previews and iframes by default. Primary source for the rendering lesson.
WhyAccess to private data, exposure to untrusted content, the ability to externally communicate. Each fine alone, catastrophic together, and the prescription is to cut one rather than defend the combination. Also the source for two lines worth memorising: “The LLM vendors are not going to save us!” and “we still don’t know how to 100% reliably prevent this from happening.” Primary source for the action-trigger lesson.
WhyThe companion post from the day before, and the one that named the problem. Argues models are black boxes and that every model upgrade restarts mitigation work from scratch — which is why a mitigation that was measured once is not a mitigation that stays measured.
WhyThe canonical payload shape for markdown image exfiltration. The detail worth carrying is not the payload but the response: after disclosure in April 2023, OpenAI indicated image markdown injection was a feature and no changes were planned. Note that the vendor’s side of that exchange is reported here rather than quoted.
WhyA CSP restricting images to Google domains was in place and was bypassed by routing through Google’s own Apps Script. The lesson generalises: an allow-list is only as tight as its most permissive entry, and large organisations have permissive entries.
WhyThe variant that breaks the “we disabled images” answer. Not an image — a Markdown link which, when clicked, passes private data in the query string. The label was “click here to reauthenticate”, which is the point: the model writes the label, so the click is a formality the attacker gets to design.
WhyIndirect injection planted in code the assistant could read. Worth having in the list because it moves the attack out of consumer chat and into a developer tool, which is the shape most portfolio-company agentic surfaces will take.
WhyThe running index of this attack class, and his definition of it: tricking a bot into rendering a Markdown image that leaks data encoded in the URL. Two practical notes — /tags/markdown-exfiltration/ is an alias serving the same page, and pagination works as ?page=2 while /2/ returns a 404.
WhyThe case that should change how you read mitigations. GitHub’s Camo image proxy — built as a privacy control — became the exfiltration channel: a pre-generated Camo URL per character, private code emitted base16-encoded as a sequence of allow-listed pixel loads. GitHub’s fix was to disable image rendering in Copilot Chat entirely, in August 2025. The mechanism is verifiable; treat the severity framing as coming from someone with a product to sell. A CVSS score appears in the post and a CVE number does not — secondary outlets name one, and this course did not verify it.
WhyCamo described in GitHub’s own words, as a privacy proxy that anonymises URLs so third parties cannot track readers. Included precisely because it is a privacy control, not a security boundary — which is what CamoLeak demonstrated the hard way.
WhyThe header reference. Note the canonical path now includes /Reference/; older links under /Web/HTTP/Headers/ redirect, so a bookmark from a year ago still works but is not what MDN self-links.
Why“specifies valid sources of images and favicons.” This is the directive that turns “the renderer might emit a remote image” into “the browser will refuse to fetch one.” MDN never uses the word proxy — routing images through your own origin is an architectural recommendation built on documented host-source mechanics, not advice MDN gives.
Why“restricts the URLs which can be loaded using script interfaces.” MDN’s current list covers fetch(), fetchLater(), XMLHttpRequest, WebSocket, EventSource, Navigator.sendBeacon() and the ping attribute — the deferred-fetch entry being a reminder that this list grows.
WhyRestricts the URLs usable as the target of a form submission. Carries a live caveat worth knowing before you rely on it: whether it should block redirects after submission is debated and browser implementations are inconsistent.
WhySource for the phrase “injection sinks”, and for the myth-killer most front-end engineers still carry: preventing script elements from executing “is susceptible to many other ways that attackers can craft HTML to run malicious JavaScript.”
WhyOn the standards track, with a banner reading “Limited availability.” The API also reshaped: the Sanitizer object is now a configuration you pass to setHTML(), and the older Sanitizer.sanitize() method no longer exists — so a tutorial written against the earlier proposal will not run.
WhySupport at the date checked, from MDN’s own compatibility data: Chrome 146, Edge 146, Firefox 148, Opera 130, and no support in Safari, Safari iOS or Samsung Internet. This is the single most perishable fact in the course — re-check it before repeating it, and never take “just use the Sanitizer API” from someone who has not.
WhyBaseline since September 2025. The inversion is the teachable fact: the variant that does not sanitise is the one available everywhere, and the safe one is not.
WhyThe load-bearing dependency in practice, because it covers Safari where the native API does not. Read its release history rather than just installing it: version 3.4.14, published 19 August 2026, fixed possible bypasses when risky tags are allow-listed. That is the same lesson as Bard and Camo, one layer down — the bypass lives in the allow-list you widened.
WhySix named patterns: Action-Selector, Plan-Then-Execute, LLM Map-Reduce, Dual LLM, Code-Then-Execute, Context-Minimization. Used in this course for vocabulary only — knowing the names lets you ask which pattern a system is closest to and what was given up to get there, which is a question that gets answered. It deliberately does not teach implementation.
WhyHis read on why the paper is credible: each pattern buys security by giving up some generality, and the authors say so rather than claiming a universal fix. Useful as a model for how to evaluate any proposed mitigation you are shown.
Why“Prefetching happens when a Link component enters the user’s viewport” and “Prefetching is only enabled in production.” Read the scope carefully before repeating it: this is client-side, same-origin navigation, so a model-supplied external URL is not what gets prefetched. The general point survives — a link component fetches before the click, in production and not in development, which is the worst combination for noticing it.
The other direction of leak, where nothing is being attacked and personal data walks out through telemetry somebody added on purpose — plus the regulation and case law that decide whether that matters. Every session-replay and observability vendor below is documenting its own product, and every LLM-observability vendor named here sells the tooling this module teaches you to interrogate. The primary law is cited instead of a summary because this is where summaries are most confidently wrong.
WhyThe most conservative default of the group: “By default, the Session Replay SDK will mask all text content with *”, plus masked inputs and blocked media. It also tells you to verify your masking configuration before enabling replay in production, which is advice worth taking from a vendor with no incentive to give it.
WhyVerified: inputs are masked, because any input element is “highly likely to contain sensitive text such as email or password.” Deliberately NOT stated here: whether general page text is masked. Two research passes could not find a PostHog page saying either way, and several plausible doc URLs 404 or truncate. That gap is the point — “I could not determine the default from the vendor’s own documentation” is itself a finding worth raising, and it is a better sentence than a guess.
WhyStates that mask is the default when the privacy level is unspecified, covering HTML text, user input, images, links and data-* attributes. But the browser SDK upgrade guide says defaultPrivacyLevel became mask-user-input in v7, previously mask — and both cannot be true of a current install. Never state a Datadog default without naming the SDK major version. The real lesson is that a masking posture can flip during a routine dependency upgrade, silently, and the vendor’s own docs may disagree about what it is now.
WhyThe other half of the Datadog contradiction, and the reason the review-surface lesson insists on a major version before any default is stated: this guide says defaultPrivacyLevel is mask-user-input in v7, previously mask, while the privacy-options page says mask is the default when unspecified. Both cannot describe one current install. The teachable point is not that either page is wrong — it is that a masking posture can change during a routine dependency upgrade, silently, with no visible effect except that the replays get more useful.
WhyThe opposite pole from Sentry: it will not record input elements of type password, and “all other elements are captured by default.” Both the input and text sanitizers default to off. Not a criticism of the product — a description of what installing it does before anyone configures it.
Why“By default, the masking mode is set to Balanced”, and Balanced masks only numbers and email addresses. Also carries a caveat rarely found in this genre: it does not mask content within style sheets or style tags.
WhyUnder Private by Default, “no text is captured or sent outside the user’s browser unless it is explicitly allowlisted as safe to capture” — the strongest posture of the group, with three element treatments running Exclude, Mask, Unmask. One conditional to hold onto: the page describes Private by Default as something configured during account setup, so “Fullstory masks all text” is not a claim you can make about an arbitrary install without checking that account.
WhySeven session-replay firms studied, found on 482 of the Alexa top 50,000, with the finding that matters here: “text typed into forms is collected before the user submits the form.” Leaks included passwords, card numbers and medical conditions. One nuance to keep straight — this is a blog post, not the similarly named peer-reviewed PoPETs paper, which covers login-manager abuse and whole-DOM exfiltration rather than session replay. Do not cross-cite them.
WhyThe session-replay wiretapping case: the tool “captured in real time every second of his interaction… and created a video recording”, and the court held that California’s CIPA § 631(a) requires prior consent, so a retroactive privacy-policy consent was insufficient. Marked NOT FOR PUBLICATION — it is a memorandum disposition, not binding precedent, and saying so is what keeps you credible with a lawyer.
WhyThe more recent of the two, and the reason this is not a settled area of law: the panel held that “The district court erred in dismissing Mikulsky’s claim under the California Invasion of Privacy Act”, on allegations that the defendants conspired with session-replay code providers to read message contents in transit. Also an unpublished memorandum. Read alongside district-court decisions going the other way — the theory is live and contested, which is exactly what makes this a question for counsel rather than for you.
WhyIncluded as a correction, not as support. This is not a session-replay case — the technology was a marketing tracker capturing clicks and form-field tabbing under Pennsylvania’s wiretapping act. It is the theory these suits build on, and calling it a session-replay case overstates it in a way a lawyer will catch immediately.
WhyThe cleanest log-leak case study with a first-party source: unsanitized internal logs contained npm access tokens, a small number of passwords used in sign-in attempts, and some GitHub Personal Access Tokens. Nobody was attacking the logging system; the data was simply written down.
WhyWorth reading for how carefully it is worded. Meta’s own phrase is “internal data storage systems”, not “logs” — the press coverage says logs. Quote the company, not the coverage, and notice how much of what you think you know about incidents comes from the summary rather than the statement.
WhyThe primary source for the trace-view lesson, and the one sentence that makes “observability logs everything by default” a citable claim rather than folklore: “Observability platforms (Langfuse, LangSmith, Datadog LLM Observability) log full prompts, completions, chunks, and traces by default.” Use the named list, never a generalisation to all observability tooling — the session-replay group above contains a vendor that masks everything by default, so the generalisation is false. Also the source for the wider surface — “disclosure surfaces extend beyond final answers to include tool-call arguments, reasoning traces, retrieved chunks, multimodal output, logs, telemetry, embeddings, and observable inference properties” — and for the two mitigations the retention lesson leans on: never log raw traces to unrestricted observability, and technically enforce no-train/no-retain rather than policy text alone. State the edition: this is LLM02:2026, entries moved between editions, and the obvious genai.owasp.org URL still serves the 2025 list.
WhyCited by the trace-view lesson for the description of what a trace is — “a hierarchical tree representing the full execution showing the exact inputs, outputs, and metrics for each node” — and for the fact that LangSmith’s own terms prohibit PII from being logged to the service. The load-bearing detail is structural rather than quotable: the page documents three separate redaction mechanisms (an environment variable that hides inputs and outputs wholesale, custom masking functions, and regex anonymisers). A vendor ships three overlapping controls for one problem when no single one is complete, which is why “we redact PII” always needs a follow-up about which mechanism, applied where.
WhyCited by the trace-view lesson for exactly two things and no more: the requirement that “instrumentations that support it MUST offer the ability to turn off capture of prompts and completions”, and the warning that end users “may input sensitive information or personally identifiable information (PII) that they do not wish to be sent to a telemetry backend.” Do NOT use this as the source for prompt capture being on by default — the conventions require an off-switch to exist and say nothing about any instrumentation’s shipped default. That claim belongs to OWASP LLM02:2026 above, and attributing it here is the misreading the lesson calls out by name.
WhyChapter V is titled “Transfers of personal data to third countries or international organisations”, and the three articles you need names for are 44 (General principle for transfers), 45 (Transfers on the basis of an adequacy decision) and 46 (Transfers subject to appropriate safeguards). Article 4(1) defines personal data as “any information relating to an identified or identifiable natural person”, and Article 9 covers special categories — health, biometrics for identification, and the rest — whose processing “shall be prohibited” absent a listed condition. Cited instead of a vendor summary because residency is the area where summaries are most confidently wrong.
WhyWhat an adequacy decision actually buys: personal data can flow “without any further safeguard being necessary”, and such transfers “will be assimilated to intra-EU transmissions of data.” The list includes the United States, but only for commercial organisations participating in the EU–U.S. Data Privacy Framework — a participation status you can check per vendor, which is what makes this a question with an answer.
WhyCase T-553/23. The General Court dismissed the action for annulment against Commission Implementing Decision (EU) 2023/1795, which remains in force. Two qualifications are the whole reason to read the release rather than the headline: the Court confirmed adequacy as at the date the decision was adopted, not permanently, and noted the Commission may suspend, amend or repeal it. An appeal (Case C-703/25 P) was lodged in October 2025 and no Court of Justice judgment exists. This is a live area — treat any claim about the framework’s status, including this one, as needing a re-check before you repeat it.
WhyThe reason residency is a live question rather than a settled one, and worth reading in full because it is two pages. On 29 June 2026 the US Supreme Court decided Trump v. Slaughter, overruling Humphrey’s Executor and removing the for-cause protection that had shielded FTC Commissioners from removal. The Data Privacy Framework adequacy decision explicitly relies on that protection at recitals 58–60. The EDPB therefore asks the Commission “to closely assess whether this development affects the functioning of Commission Implementing Decision EU 2023/1795.” Read the verb carefully: it asks for an assessment, not a suspension — a summary of this letter that says otherwise is wrong, and one produced during the research for this course did.
WhyThe plainest statement of the shape of the rule: transfers outside the EEA “are often essential” and are permitted where they comply with Chapter V, via an adequacy decision, appropriate safeguards, or a derogation. Nothing here requires data to stay in the EU. This course still states “GDPR restricts transfers rather than mandating localisation” as an inference from that structure, because no authority was found putting it in those exact words.
WhyUsed by the retention lesson for one purpose only: to draw a contrast, not to support a claim about anyone’s product. OpenAI documents a default 30-day retention window on chat completions for abuse-monitoring purposes. That is the model vendor’s API-layer logging — a bounded, published number describing a system your company does not run — and it says nothing whatsoever about a product’s own transcript database, which is a table your team wrote and is bounded by nothing unless someone bounded it. A team answering a retention question with this figure has answered about the wrong database, and that substitution is the specific thing the lesson teaches you to listen for.
Two standards bodies and one independent engineer, plus an honest admission: the escalation discipline this module teaches — one owner per flag, a non-blocking proposal, a written pass condition — is the course’s own, and none of these documents contains it. Note also who is missing. Almost everything that ranks for “what is SOC 2” is published by companies selling compliance automation and remediation, so this group cites AICPA directly and says why.
WhyThe one-sentence definition the SOC 2 lesson opens on: “A SOC 2 examination is a report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy.” Report, controls, relevant to — all three words carry weight. The old us.aicpa.org path 301s here; do not cite the old URL.
WhyCited in the SOC 2 lesson for the correction that most explainers get wrong. AICPA does not say Security is a required category: it says the common criteria are “criteria common to all five of the trust services categories”, that they suffice for security, that a practitioner may report on any category individually or in combination, and that “although uncommon, there may be circumstances in which the security category is not addressed.” The 2022 revision changed points of focus only — it did not alter the 2017 criteria. Search-result trap: a well-ranked AICPA CDN PDF is the pre-2022 document.
WhyWhere the telemetry hook lives, and the primary source for the SOC 2 lesson. A subservice organization is “a vendor used by a service organization that performs controls that are necessary, in combination with controls at the service organization…”, and a vendor “might also be a subservice organization” — which is how a front-end dependency crosses an audit boundary. Under the carve-out method its system components “are excluded from the description… and from the scope of the examination”; under the inclusive method its controls “are subject to the service auditor’s examination procedures.” DC7 governs, and one description may carve out some and include others. Also the source for “there are two types of SOC 2 examinations (type 1 and type 2)”, type 2 adding “the operating effectiveness of controls.”
WhySource for the attestation structure the SOC 2 lesson teaches in place of a sentence AICPA never wrote: reports are “examination engagements performed by a service auditor in accordance with SSAE No. 18… AT-C section 105… and AT-C section 205”, issued by a licensed CPA, and the logo is a twelve-month licence tied to a report rather than a certificate. The honest limitation is the reason it is here: AICPA does not anywhere say “SOC 2 is not a certification” in those words, and every source that does is a compliance-automation vendor or an audit-firm blog. Teach the structure; do not put the sentence in AICPA’s mouth.
WhyAICPA’s own, vendor-independent commentary on the compliance-automation tooling that publishes most of the internet’s SOC 2 explainers: “a number of software solutions…have been introduced that are designed to improve the efficiency with which service organizations can prepare for and undergo SOC 2 examinations.” Cited in the SOC 2 lesson, with the limit stated in the prose — the PDF itself is account-gated and only the page-level snippet was verified.
WhyPrimary source for two lessons, at two different sections. The ownership lesson takes GOVERN 2.1 — “Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization” — plus §1.2.4, “Different AI actors have different responsibilities and awareness depending on their roles in the lifecycle.” The non-blocking lesson takes §1.2.3, “Attempting to eliminate negative risk entirely can be counterproductive in practice because not all incidents and failures can be eliminated”, and its counterweight, that where risk levels are unacceptable “development and deployment should cease in a safe manner until risks can be sufficiently managed.” MANAGE 1.3 supplies the four response options — “mitigating, transferring, avoiding, or accepting” — and MANAGE 1.4 the requirement that negative residual risks are documented, which is what makes a recorded acceptance a real closure. Read the limit carefully: NIST asks that roles be documented and clear. It does not say one role per flag, and it says nothing at all about writing a pass condition. Both of those narrower rules are this course’s own.
WhyPrimary source for the pass-condition lesson, generalised one step beyond what it argues. “When you’re engineering for security, a solution that works 99% of the time is no good” is a test for controls; this course applies the same test to answers, and says so. The SQL-injection contrast is the clearest illustration available of a guarantee versus a hope: “There is a known, guaranteed to work mitigation against SQL injection attacks: you correctly escape and quote any user-provided strings…Trying to prevent AI attacks with more AI doesn’t work like this.” Also the argument to have ready in the rendered-surface module when somebody proposes an injection-detection classifier — the piece includes a payload that instructs the detector itself to report no injection.
Every claim on these pages links to its source. If a source looks wrong or out of date, check the resource list and tell your teaching agent — the course is meant to be corrected.