VU23222 Expose website security vulnerabilities

A website is a program that runs partly on a server you control and partly in a browser you do not, and that split is the source of nearly every web vulnerability. The server has to accept input from anyone, trust nothing, and still behave correctly. When it trusts something it should not (a value in the URL, text typed into a form, a header), an attacker turns that misplaced trust into a way to read data, run code in another user's browser, or reach records they were never meant to see. This unit is the disciplined study of where that trust breaks.

The authorisation boundary is as firm here as anywhere in the certificate, and the VU23223 legislation unit states it plainly: testing a website you do not own, or do not have written permission to test, is illegal in Australia regardless of intent. Everything on this page assumes a deliberately vulnerable practice application in an isolated lab, or a site under a written testing agreement. The same web vulnerabilities appear in the VU23226 exploitation unit's website lab; the difference is only depth, not the rule.

The performance evidence asks for two things done end to end: showing how OWASP guidance secures a site, and using tools to expose vulnerabilities in two scenarios. So each vulnerability below is worth learning twice over: how to expose it with a tool, and which OWASP outcome tells you how to close it. The final assessment is a written penetration test report, so the reporting phase at the end of this page is not an afterthought; it is the deliverable the unit is really assessing.

Before testing a site you have to understand how it is built, because each part is a different kind of target. A modern web application is not one program but several tiers working together, and the first element of the unit asks you to explain that architecture.

flowchart LR Client["Client<br/>browser (untrusted)"] --> LB["Load balancer<br/>distributes requests"] LB --> WS["Web server<br/>Apache, Nginx, IIS"] WS --> AS["Application server<br/>app logic, Python/Node/Java"] AS --> DB["Database server<br/>MySQL, PostgreSQL, MongoDB"]

The client is the user's browser, which initiates every request and is entirely outside the server's control. A load balancer, where present, spreads incoming requests across several servers for capacity and resilience. The web server (Apache, Nginx or Microsoft's IIS) receives requests and serves files or hands dynamic requests on. The application server runs the actual application logic, and the database server stores and retrieves the data the application works with. Understanding this shape tells a tester where a given weakness lives: a misconfigured security header is a web-server problem, SQL injection is an application-and-database problem, and a missing patch could be in any tier.

The technology stack is the specific set of products filling those roles, and identifying it is performance criterion 2.1 because it shapes the whole test. A stack has an operating system (a Linux distribution such as Ubuntu, or Windows Server), web server software (Apache, Nginx or IIS), a back-end layer (a language such as Python, Node.js or Java, a framework such as Django, Express or Spring Boot, and a database such as PostgreSQL, MySQL or MongoDB), and a front-end layer (HTML, CSS and JavaScript, often built with a framework such as React, Vue or Angular). Fingerprinting the stack early, from response headers, error messages, cookies and file extensions, turns a blind test into a focused one, because a known product and version can be matched straight to known vulnerabilities.

Update, current as at September 2026. A current stack frequently has a fourth tier the unit's diagram does not show, and it needs fingerprinting like any other: a model endpoint (a hosted API such as those from Anthropic, OpenAI or Google, or a locally served model), a vector database holding embedded documents for retrieval (Pinecone, Weaviate, pgvector, Chroma), an orchestration framework (LangChain, LlamaIndex or similar), and increasingly a tool or context layer such as a Model Context Protocol server through which the model reaches other systems. Each is a component with its own version, its own vulnerabilities and its own trust assumptions. If a site has a chat feature, a summarisation button, a semantic search box or an "ask about this document" panel, that tier is present, and the sections near the end of this page describe how it fails.

The Hypertext Transfer Protocol is a simple request-and-response conversation, and the second element asks you to describe its structure and operation. A browser sends a request (a method, a path, a set of headers, and sometimes a body) and the server sends a response (a status code, a set of headers, and usually a body of HTML). HTTPS is the same conversation carried inside a TLS-encrypted channel so it cannot be read or altered in transit.

sequenceDiagram participant B as Browser (untrusted client) participant S as Web server (trust boundary) participant D as Database B->>S: HTTP request (method, path, headers, body) S->>D: query built from the request D-->>S: results S-->>B: HTTP response (status, headers, HTML) Note over B,S: every value from the browser is attacker-controlled

The request methods name the intended action: GET retrieves a resource, POST sends data to be processed, PUT updates a resource, and DELETE removes one. Status codes report the outcome, and a tester learns the families quickly: 200 means success; the 300s are redirection (302 is a temporary redirect, often the jump from HTTP to HTTPS); the 400s are client errors (401 unauthorised, 403 forbidden, 404 not found); and the 500s are server errors, which sometimes leak useful detail when an application mishandles an exception.

Two properties of this design create most of the unit's content. HTTP is stateless: each request stands alone with no memory of the last, so applications track a logged-in user with a session identifier carried in a cookie, which is what makes that cookie worth stealing. And every part of the request comes from the client, so every part is attacker-controlled; a header, a cookie, a URL parameter and a form field are all just text the server chose to trust. One efficiency feature is worth naming because the syllabus tests it: persistent connections, introduced in HTTP/1.1, let a single TCP connection carry many request-and-response pairs instead of opening a new one each time.

Update, current as at August 2026. Most of the web has moved beyond HTTP/1.1. HTTP/2 (multiplexing many requests over one connection) and HTTP/3 (built on the QUIC transport rather than TCP) are now widely deployed, and testing tools handle them, though the request-and-response model a tester reasons about is unchanged. The durable point is that HTTPS is now effectively universal and expected; a site served over plain HTTP is itself a finding.

You cannot test what you cannot see, so reading raw requests and responses is the first practical skill, and it maps to performance criteria 1.3 and 1.4. HTTP headers are the metadata that travels with each request and response, and they serve several roles: information exchange (declaring the type and format of the content), caching (controlling whether and how content is stored for reuse), session management (carrying the cookies that track a logged-in user), security (the hardening headers in the next section), redirection (pointing the browser to a new location), and custom data (application-specific headers).

There are several ways to inspect them. The command-line tool curl, with its -I option, requests only the headers and prints both the request and response detail, which is the quickest way to check a single site. A browser's developer tools (in Chrome or Firefox) show the headers of every request and response as you browse. And for the deeper view the unit's own lab uses, Wireshark captures the actual packets on the wire, so you can watch an HTTP conversation unfold and see exactly what plain HTTP exposes and HTTPS conceals. Reading a 401 Unauthorized response with a WWW-Authenticate header, or a 302 Found with a Location header pointing at the HTTPS version of a site, is the kind of small, concrete skill the questioning task checks.

The unit names the OWASP Secure Headers Project directly in its assessment resources, so the response headers a server sends are examined here as a defence in their own right, satisfying performance criteria 1.5 and 1.6. Several headers turn browser features into security controls:

Content-Security-Policy (CSP): tells the browser which sources of scripts, styles and other content are allowed, which is the strongest single defence against cross-site scripting because it stops injected scripts from running even if they reach the page.

Strict-Transport-Security (HSTS): tells the browser to use HTTPS only for this site, closing the window in which a first request could be downgraded to plain HTTP.

X-Frame-Options and the CSP frame-ancestors directive: control whether the site can be embedded in a frame on another site, which defeats clickjacking.

X-Content-Type-Options: stops the browser from second-guessing (MIME-sniffing) the declared content type, a trick attackers have used to make a file run as script.

Cookie attributes (HttpOnly, Secure, SameSite): keep session cookies out of reach of scripts, off unencrypted connections, and away from cross-site requests.

The Secure Headers Project's real value is that it also points at tools to test these headers, which the unit asks you to examine. SecurityHeaders.com scans a public site and grades its headers; the Mozilla Observatory (observatory.mozilla.org) does the same with broader best-practice checks; curl and the browser developer tools give the manual view; and the intercepting proxies below (Burp Suite and OWASP ZAP) let you inspect and modify headers during a full test. Checking these headers is one of the quickest wins in a web test, and "the site is missing HSTS and a Content-Security-Policy" is a legitimate, well-evidenced finding with a clear OWASP-backed remediation. The underlying transport matters too: current practice is TLS 1.2 or 1.3 only, with the older SSL and early TLS versions disabled.

The unit is built explicitly on OWASP outcomes, so knowing what OWASP produces is core, not background. The Open Web Application Security Project is a non-profit foundation that publishes free, vendor-neutral web security resources. The ones worth naming:

The OWASP Top 10 is the best-known: a periodically updated list of the most serious categories of web application risk, used across the industry as a baseline. The Web Security Testing Guide (WSTG) is the detailed methodology, a step-by-step catalogue of how to test each type of weakness, and it is the natural backbone for the two scenarios the unit asks for. The Application Security Verification Standard (ASVS) is a checklist of security requirements at graded levels of rigour. The Cheat Sheet Series gives concise, practical fixes for each vulnerability class. OWASP Juice Shop is a deliberately vulnerable practice application, and Cornucopia is a secure-design card game; both are genuine OWASP projects, which is the sort of distinction the questioning task probes.

Two further OWASP bodies of work now sit alongside the web Top 10 and are covered in their own sections later on this page: the GenAI Security Project, which publishes the GenAI LLM Top 10, and its Agentic Security Initiative, which publishes the Top 10 for Agentic Applications. They are separate projects with their own numbering, so a finding is cited as LLM01:2026 or ASI01:2026 rather than being forced into a web Top 10 category.

Update, current as at August 2026. The unit's Assessor Guide refers to the OWASP Top 10 2021. OWASP published a new Top 10 for 2025 (finalised in November 2025 after a release-candidate period), and the ranking has changed in ways worth teaching. Broken Access Control remains the number one risk; Security Misconfiguration rises to second; and a new category, Software Supply Chain Failures, enters at third, recognising that most applications are largely other people's code and their build pipelines are now a prime target. Injection, which covers SQLi and XSS, sits at A05 in the 2025 list, and a second new category, Mishandling of Exceptional Conditions, also appears. The three vulnerabilities the unit names by hand (SQLi, XSS and IDOR) are all still squarely in the current Top 10; only their framing and numbering have moved. Whenever you cite the Top 10, name the year, because the list has been renumbered twice in the life of this course.

Before you can test a site you have to know what is there, and the second element's later criteria are about mapping the target. Spidering, also called web crawling, is the automated process of following links from page to page to build a map of the application; a spider fetches a page, extracts its links, and follows them, and testing proxies include one. Spidering finds what the site links to, but not what it hides, so it is paired with content discovery, which brute-forces likely directory and file names from a wordlist to find pages that are present but unlinked (an old admin panel, a backup file, a test script).

The tools the unit names sort into two jobs. Nikto is a web server scanner that checks for known-dangerous files, outdated server software and common misconfigurations across thousands of checks; it is a quick first pass that flags the obvious. DIRB is the named content scanner, which brute-forces directories and files against the server and reports what exists. Update, current as at August 2026: DIRB still runs but is effectively unmaintained, and current practice has moved to faster tools that do the same job, chiefly ffuf, gobuster and feroxbuster; the technique is identical, so the DIRB knowledge transfers directly. Beyond these, dedicated web vulnerability scanners (the scanner built into Burp Suite Professional, OWASP ZAP's active scanner, and Nikto for the server layer) automate the checking of many known issues, though a scanner finds only what it has a rule for and never replaces manual testing of the application's own logic.

The intercepting proxy is the centre of web testing, and installing and using one is the whole of the third element. It sits between the browser and the site, letting you see, pause and modify every request and response before it goes on, which is what makes it possible to test values the interface would never let you send.

Burp Suite, named in the unit, is the industry standard. It is a suite of tools around the proxy: a spider to map the site, a scanner to find known issues (in the paid Professional edition), an intruder for automated, customised request attacks, a repeater for hand-crafting and resending single requests, plus a sequencer, decoder and comparer for supporting analysis. Its free Community Edition covers the core proxy and repeater, which is enough for this unit. OWASP ZAP (the Zed Attack Proxy) is the strong free and open-source alternative and does much the same job, which makes it the natural choice for a self-funded lab. Configuring the proxy means pointing the browser's traffic through it and installing the proxy's certificate so it can read HTTPS, after which every request the site makes is visible and editable.

The distinction between SAST and DAST, named in the knowledge evidence, completes the toolkit picture. Static application security testing (SAST) examines the application's source code without running it, catching flaws early in development; dynamic application security testing (DAST) tests the running application from the outside, the way an attacker meets it. The proxies and scanners above are DAST tools. The two are complementary: SAST finds a flawed line of code, DAST proves the flaw is reachable and exploitable on the live site, and a mature program uses both across the development lifecycle. sqlmap (for SQL injection) and Nuclei (a template-driven scanner for known issues) round out the current kit.

Update, current as at September 2026. Two additions to the toolkit picture. Scanners and proxies have begun shipping checks aimed at language model features, and dedicated model testing tools have appeared alongside them, though this part of the market is young and no tool has yet become the standard the way Burp did for the proxy. Separately, AI assistance is now common in the testing workflow itself, for reading unfamiliar code, drafting payload variations and writing up findings. The judgement it does not replace is deciding whether a finding is real and what it is worth, and an unverified AI-suggested finding in a penetration test report is a professional failure, not a time saving. Everything in a report is still evidenced by a request, a response and a reproduction.

SQL injection is the classic web vulnerability and the first the unit asks you to demonstrate. It happens when user input is placed into a database query as though it were part of the query's code rather than data. If a search box builds its query by pasting the user's text straight in, an input like coffee' OR '1'='1 adds an always-true condition that makes the database return every row, and more dangerous inputs can read other tables, change data or, on a misconfigured server, run commands. The forms worth knowing are error-based (the application returns database errors that leak structure), union-based (using SQL's UNION to append attacker-chosen data to the results), and blind (inferring data one true-or-false question at a time when no output is visible). The tool the field uses to find and exploit it is sqlmap, which automates detection and extraction. The fix is not filtering bad words; it is parameterised queries (also called prepared statements), which send the query structure and the user's data to the database separately so the data can never be read as code. Input validation and least-privilege database accounts are the supporting controls.

Cross-site scripting is injection aimed at the browser instead of the database, and the second vulnerability the unit asks you to demonstrate. It happens when an application takes user input and places it into a page without neutralising it, so the input runs as script in the next person's browser, where it can steal their session cookie, act as them, or rewrite the page. There are three forms worth distinguishing: reflected XSS, where the payload is in the request and bounced straight back in the response (often via a crafted link); stored XSS, where the payload is saved by the application (in a comment or a profile field) and served to every later visitor, which is the most damaging; and DOM-based XSS, where the flaw is in the page's own client-side JavaScript. The defence is output encoding (rendering user input as inert text, not markup) backed by a Content-Security-Policy, and framework auto-escaping now handles much of this by default, which is why the current advice is to use a modern framework's templating rather than build HTML by hand.

The Browser Exploitation Framework (BeEF), named in the unit's knowledge evidence, shows what XSS is actually worth to an attacker: once a payload "hooks" a victim's browser, BeEF gives a control panel to run further actions through that browser, using it as an attack vector against the target. It is a vivid demonstration of impact. Update, current as at August 2026: BeEF is still available and useful for teaching, but its real-world reach has narrowed as browsers have hardened and Content-Security-Policy has spread, so treat it as an illustration of why XSS matters rather than as a current attack platform.

Broken access control has been the number one web risk in both the 2021 and 2025 Top 10, and the insecure direct object reference (IDOR) the unit names is its most common concrete form, and the third vulnerability you are asked to demonstrate. IDOR happens when an application uses a value from the request (a record number in the URL such as ?id=7) to fetch data without checking that the current user is allowed that record, so changing 7 to 8 returns someone else's invoice, message or account. It is dangerous precisely because it needs no special tools; a browser and a guessable identifier are enough. The fix is a server-side authorisation check on every request that touches a record, tied to the logged-in user, rather than relying on the interface simply not showing the link. The broader category covers any case where a user can act outside their intended permissions, including reaching admin functions by guessing their URLs.

The fourth element pairs the injection and access-control weaknesses with authentication and session flaws, because a stolen or forged session is often the whole attack. Once a user logs in, the application issues a session identifier (usually in a cookie) that stands in for their credentials on every later request, so anything that lets an attacker obtain, guess or set that identifier hands them the account. Three attacks the unit names show the range:

Credential stuffing: the attacker replays username and password pairs leaked from other breaches, betting that people reuse passwords. It is countered by rate limiting, multi-factor authentication, and warning users about known breaches.

Session hijacking: the attacker steals a valid session identifier, often by sniffing unencrypted traffic or through XSS, and uses it to impersonate the victim. It is countered by HTTPS everywhere, the Secure and HttpOnly cookie flags, short session timeouts, and rotating the session token after sensitive actions.

Session fixation: the attacker sets a victim's session identifier to one the attacker already knows, then waits for the victim to log in with it. It is countered by issuing a fresh session identifier at login.

The kill chain of a man-in-the-middle session hijack ties this section to VU23215: the attacker positions between the victim and the server (classically by ARP spoofing on a shared network), intercepts the traffic, lifts the session cookie or credentials, and takes over the session, then may exfiltrate data and cover their tracks. The lesson is why the controls above exist: encryption defeats the interception, the HttpOnly flag keeps script from reading the cookie, and short-lived, rotated sessions limit what a stolen token is worth.

Beyond the four the unit demonstrates, a competent web tester recognises a handful more, because the questioning task lists them and they come up constantly. Cross-site request forgery (CSRF) tricks a logged-in user's browser into making an unwanted authenticated request, countered by anti-CSRF tokens and the SameSite cookie attribute. Server-side request forgery (SSRF) tricks the server into making requests on the attacker's behalf, often to reach internal systems. Directory traversal uses crafted paths (such as ../../) to read files outside the web root. XML external entity (XXE) injection abuses an XML parser to read local files or reach internal services. And clickjacking overlays a transparent layer so a user clicks something other than what they see, countered by the frame-control headers above. Each is a category to recognise and map to an OWASP outcome, alongside the newer 2025 entries (security misconfiguration and software supply chain failures) already noted.

Everything above this point describes the web application as the unit was accredited to teach it. This section and the two after it describe the part of the attack surface that did not exist then, and it belongs in this unit rather than somewhere else for a plain reason: a large language model feature in a web application is reached over HTTP, through the same request and response conversation, and it is tested through the same intercepting proxy. The chatbot on a company's support page is an HTTP endpoint. Burp and ZAP see it. The performance criteria that ask you to investigate existing frameworks that identify common software vulnerabilities, and to identify the most common web security vulnerabilities, are satisfied by the OWASP Top 10 as the unit intends; they are satisfied better by also knowing the two lists below, because for a growing share of the applications a technician is asked to test, this is where the vulnerabilities now are.

The argument the page opened with holds without modification. A web application is a program that has to accept input from anyone, trust nothing, and still behave correctly, and vulnerabilities happen where it trusts something it should not. An LLM feature is the most extreme case of that problem ever built into a web application, because the model has no mechanism at all for separating the instructions its developer gave it from the text a user supplies. Both arrive as language in the same context window. That is not a bug in a particular product; it is the shape of the technology.

The list

OWASP's work on this sits in the OWASP GenAI Security Project, a separate project from the web Top 10 and worth knowing as its own body of work. Its flagship list is the OWASP GenAI LLM Top 10. The 2026 edition was released on 3 August 2026, and it is the first edition weighted partly by incident data rather than expert consensus alone; the project states that expert voting carried 75 per cent of the weight and data from 6,639 real incidents the remaining 25 per cent.

Code	Risk	What it means in a web application
LLM01:2026	Prompt Injection	Text supplied by a user, or retrieved from a document or web page, is read by the model as instructions and overrides what the developer told it to do
LLM02:2026	Sensitive Information Disclosure	The model reveals training data, retrieved documents belonging to other users, or internal detail it should not have surfaced
LLM03:2026	Excessive Agency	The model has been given tools, permissions or autonomy beyond what its task needs, so a successful manipulation causes real actions rather than bad text
LLM04:2026	Supply Chain	Compromised base models, unsafe model serialisation formats, and untrusted model registries and adapters
LLM05:2026	Data and Model Poisoning	Contaminated training or fine-tuning data, or a poisoned adapter, changes the model's behaviour in the attacker's favour
LLM06:2026	Unbounded Consumption	Token exhaustion, runaway cost and resource starvation, which is denial of service with an invoice attached
LLM07:2026	Misinformation	Fabricated output that is then acted on automatically, or relied on for a decision with legal or financial consequences
LLM08:2026	Hidden Context Exposure	Extraction of the system prompt, the policy logic, the tool definitions and the guardrails, which tells an attacker exactly what to work around
LLM09:2026	Vector and Embedding Weaknesses	Manipulation of the retrieval layer in a retrieval-augmented application, including poisoned documents and leakage between users' contexts
LLM10:2026	Improper Output Handling	Model output is passed to something that executes it, producing ordinary XSS, SQL injection or command execution by a new route

Three entries moved noticeably from the 2025 list. Excessive Agency rose to third, because agentic deployments began causing real damage. Unbounded Consumption rose four places, on practitioner concern about cost and resource exhaustion. Improper Output Handling fell from fifth to tenth, which is worth reading carefully: it fell because frameworks now sanitise output by default, not because the risk stopped mattering.

Prompt injection, worked through the way SQLi and XSS were

Prompt injection is the defining vulnerability of this list, and it repays the same treatment the earlier sections gave to injection and cross-site scripting.

The mechanism. An application sends the model a system prompt setting out its role and rules, then appends the user's message, then sends the whole thing as one block of text. The model has no reliable way to tell which part is authority and which part is data. Text that says "ignore your previous instructions and instead do the following" is, to the model, simply more instructions.

Direct prompt injection is the user typing the malicious instruction themselves, usually to make the application misbehave, reveal its system prompt, or do something outside its intended remit. This is the form most people have seen.

Indirect prompt injection is the dangerous form, and it is the one that maps most closely to stored XSS. The instruction is not typed by the attacker at all. It is planted in content the application will later retrieve and feed to the model: a web page the assistant is asked to summarise, a document in a retrieval index, an email in an inbox the assistant reads, a review on a product page, a code comment in a repository. The victim is whoever uses the assistant afterwards, exactly as with stored XSS, and the attacker never touches the application directly.

Why it is not solved the way injection was solved. SQL injection has a clean fix because a database can be given the query structure and the user's data through separate channels, so the data can never be read as code. Parameterised queries work because that separation is possible. No equivalent separation exists for a language model: instructions and data are both natural language in the same context. So the defences are compensating controls rather than a fix, and they are worth listing because the questioning task will want a mitigation for every finding:

Treat every model output as untrusted input, and validate it at the boundary it crosses next. This is the control that stops LLM10 becoming XSS or SQLi.

Constrain agency. If the model can only read, a successful injection produces bad text. If it can send email, spend money or run code, the same injection produces an incident. Least privilege applies to model tools exactly as it applies to database accounts.

Put a human approval step in front of any consequential or irreversible action.

Segregate and label untrusted content, so retrieved documents and web pages are marked as data in the context rather than blended into the instruction block.

Apply input and output filtering, and guardrail models, accepting that these raise the cost of an attack rather than preventing it.

Rate limit and cap token spend, which addresses LLM06.

Log the full prompt, the retrieved context and the tool calls, because without that record an incident involving a model cannot be investigated at all.

OWASP's own guidance on this sits in the LLM Prompt Injection Prevention Cheat Sheet, which is the natural companion to the Cheat Sheets used earlier on this page.

Testing an LLM feature with the tools you already have

The reassuring part, and the part that makes this a web unit rather than a separate discipline. An LLM feature is an HTTP endpoint. Point the browser through Burp Suite or OWASP ZAP as before, and the requests are visible and editable in exactly the same way. What changes is what you send and how you judge the result.

Map the feature first: what the model can see (which documents, which databases, which pages), and what it can do (which tools, which APIs, which permissions). That map is the attack surface, and building it is the same exercise as fingerprinting a technology stack.

Test for system prompt disclosure, for cross-user data leakage in the retrieval layer, for whether planted content in a retrieved document changes the model's behaviour, and for what the model's output is passed to next.

Accept that testing is probabilistic. A model may refuse an input nine times and accept it the tenth, which has a direct consequence for the reporting element of this unit: reproduction steps for an LLM finding must record the exact prompt, the model and version, the settings, and how many attempts out of how many succeeded. "Sometimes" is a legitimate and important finding, but it has to be evidenced as a rate, not asserted.

An agent is an LLM that has been given tools, memory and the authority to act in a loop without a person approving each step. That is a different security problem from a chatbot, because the consequence of manipulating it is action rather than text, and because agents increasingly call other agents.

OWASP treats this as its own body of work through the Agentic Security Initiative, which published the OWASP Top 10 for Agentic Applications on 9 December 2025, peer reviewed by more than 100 contributors. The entries carry ASI codes.

Code	Risk	The short version
ASI01:2026	Agent Goal Hijack	Direct or indirect instruction injection redirects the agent's goals, plans or decision path
ASI02:2026	Tool Misuse and Exploitation	The agent abuses tools it is legitimately permitted to use, through unsafe composition, recursion or excessive execution
ASI03:2026	Agent Identity and Privilege Abuse	Delegated authority and ambiguous agent identity lead to unauthorised actions and assumed privileges
ASI04:2026	Agentic Supply Chain Compromise	Compromise of the external agents, tools, schemas or prompts the agent imports and trusts at runtime
ASI05:2026	Unexpected Code Execution	Agent-generated or agent-triggered code runs without adequate validation or isolation
ASI06:2026	Memory and Context Poisoning	Injected or leaked memory and context influences the agent's reasoning across later sessions
ASI07:2026	Insecure Inter-Agent Communication	Messages between agents, planners and executors are intercepted, injected or spoofed
ASI08:2026	Cascading Agent Failures	A small failure propagates through connected agents and tools into large-scale impact
ASI09:2026	Human-Agent Trust Exploitation	Over-reliance is exploited through misleading explanations, false authority or unwarranted certainty
ASI10:2026	Rogue Agents	Agents act beyond their intended objectives through goal drift, collusion, reward hacking or exceeding autonomy bounds

Read against the rest of this page, the pattern is familiar rather than alien. ASI01 is injection. ASI03 is broken access control, which has been the number one web risk in both the 2021 and 2025 Top 10 and is now the number one agentic risk under a different name. ASI04 is the software supply chain category that entered the web Top 10 at third place in 2025. ASI07 is a trust boundary between components with no authentication on it, which is the same failure as an unauthenticated internal API. The vulnerability classes did not change; the components between which trust is misplaced did.

Two entries genuinely are new in kind. ASI09 has no equivalent in traditional application security, because it is a vulnerability in the person rather than the system: an agent that explains itself fluently and confidently is trusted more than its accuracy warrants. And ASI08 is a systems property rather than a defect, which means it cannot be found by testing one component.

Update, current as at September 2026. This is a fast-moving area and the lists will move again. Treat the codes above as current at the date on this page, and check the GenAI Security Project site before quoting a code or a ranking in a report.

The last piece is not a vulnerability class. It is a change in the supply of vulnerabilities, and it lands directly on the risk-rating and reporting element that this unit assesses.

What happened

Anthropic announced a model called Claude Mythos Preview on 7 April 2026, aimed at cyber security work. The UK AI Security Institute published an evaluation on 13 April 2026: the model reached a 73 per cent success rate on expert-level capture-the-flag challenges, a tier no model had completed before April 2025, and was the first model to complete a 32-step simulated corporate network attack from start to finish, succeeding in 3 of 10 attempts and averaging 22 of the 32 steps. AISI's own caveat matters as much as the result: their test environments had no active defenders, no defensive tooling and no security alerting, so the evaluation does not show what the model would do against a well-defended network. Their advice was to prioritise the fundamentals, patching and access control.

Alongside it, Anthropic launched Project Glasswing in April 2026, a consortium of roughly 50 partners including Cloudflare, Mozilla, Microsoft, Oracle and Palo Alto Networks, using the model to find vulnerabilities in widely used software before attackers do. Its initial update, published 22 May 2026, reported more than 10,000 high or critical severity vulnerabilities found across partner systems in the first month, an estimated 6,202 in over a thousand open-source projects, 2,000 bugs at Cloudflare alone, and 271 in Firefox. Of the findings assessed, 90.6 per cent were valid and 62.4 per cent were confirmed high or critical.

A note on the counting, because it matters for how the numbers are read. VulnCheck's analysis of the public record, published 15 April 2026, found 75 CVE records mentioning Anthropic, 40 credited to Anthropic researchers, and only one explicitly attributed to Glasswing itself, concluding that the publicly attributable impact of the project was at that point limited. Discovery counts and published CVEs are different measurements taken at different points in a long pipeline, and quoting one as though it were the other is the most common error in commentary on this. The honest position as at September 2026 is that the discovery figures are large and come from the organisation running the project, the public CVE record lags well behind them, and the two have not yet converged.

Why a web tester should care

Because the bottleneck has moved from finding vulnerabilities to fixing them, and the reporting element of this unit sits on the fixing side.

The Cloud Security Alliance published a research note on 24 May 2026, on what it called the disclosure velocity crisis, setting out the mismatch. Of 1,596 disclosed vulnerabilities in the set it examined, 97, or about 6 per cent, had been patched as at May 2026. CVE submissions grew 263 per cent between 2020 and 2025. Time to exploitation has compressed from around 63 days in 2018 to roughly 5 days in 2026, and 28.3 per cent of CVEs are exploited within 24 hours of disclosure. NIST has acknowledged that the National Vulnerability Database can no longer keep pace with the incoming volume and has limited its enrichment to the highest-risk submissions, which means a growing share of CVEs arrive without the severity data automated triage depends on. Open-source maintainers, frequently single volunteers, cannot process disclosure queues faster than findings arrive; the note records that some maintainers asked Anthropic directly to slow its disclosure rate.

The 90-day responsible disclosure window was designed around the pace of human research. It now sits between AI-accelerated discovery on one side and AI-assisted exploitation on the other, and there is no settled view on what should replace it. Write that as the open question it is.

What it changes in the report you write

Severity alone is no longer a usable prioritisation. When a scan returns forty high-severity findings, a severity rating sorts them into one undifferentiated pile. Current practice pairs severity with likelihood of exploitation: the CISA Known Exploited Vulnerabilities catalogue lists what is being exploited in the wild right now, and EPSS, maintained by the EPSS Special Interest Group at FIRST, publishes a daily probability that a given CVE will be exploited in the next 30 days. A finding that is high severity, in the KEV catalogue and carrying a high EPSS score is a different priority from one that is high severity and has never been exploited anywhere. Saying so in the report is what makes it actionable.

Compensating controls carry more weight than they used to, because a patch may not exist or may not be deployable in time. Runtime detection, behavioural monitoring, network segmentation and a web application firewall rule are legitimate recommendations in their own right, not consolation prizes for failing to patch.

And the supply chain category earns its place at third in the 2025 Top 10. Most of the volume above is in dependencies rather than in the application's own code, which makes a software bill of materials and a dependency scanning step part of a competent web assessment rather than an optional extra.

The final element, and the unit's largest assessment, is the penetration test report; the earlier tasks exist to feed it. Reporting has four parts the unit sets out.

Assigning risk comes first. A finding is not just "present"; it carries a severity, and the factors that decide it include how easily the vulnerability can be exploited, the sensitivity of the data it exposes, the potential impact on the organisation's reputation and operations, the number of users affected, and whether a patch or fix is readily available. Structured scoring systems (the OWASP Risk Rating methodology, or CVSS from the VU23226 notes) turn these factors into a comparable rating so the most serious findings are fixed first. As the AI-scale discovery section above sets out, severity on its own no longer sorts a long findings list into a usable order, so pair it with exploitation likelihood from the CISA Known Exploited Vulnerabilities catalogue and EPSS wherever the finding maps to a published CVE.

Detailed reproduction steps come next, and they matter more than they look. A finding a developer cannot reproduce is a finding that does not get fixed, so each one records exactly how to trigger it: the URL, the input, the request, and the observed result, ideally with a screenshot. A finding in a language model feature needs more than that, because the behaviour is probabilistic: record the model and its version, the settings, the exact prompt and retrieved context, and the success rate across a stated number of attempts, so a reviewer can tell an intermittent finding from an unreproducible one. Remediation steps then say how to close it, tied where possible to an OWASP Cheat Sheet or Top 10 reference so the advice is authoritative rather than personal opinion.

The report itself has two audiences. The technical body of the report, written for developers and administrators, carries each finding with its risk rating, reproduction steps and remediation. The executive summary, written for managers and decision-makers, states in plain language what was tested, what the overall risk posture is, and what the priorities are, without the technical detail. Writing for both audiences, and presenting the findings to the relevant people, is explicitly assessed, because a test that no one acts on has achieved nothing.

Because every finding needs a mitigation, the defensive picture is worth holding as a short set of durable principles that recur across the vulnerabilities above: never trust client input, and validate it on the server; separate data from code, which is parameterised queries for SQL and output encoding for HTML; check authorisation on every request, for every object; manage sessions securely, with fresh tokens at login, short timeouts and the Secure, HttpOnly and SameSite cookie flags; configure securely, which includes the security headers, current TLS, and removing defaults and verbose errors; keep dependencies patched, the point of the new supply-chain category; and build security in across the software development lifecycle rather than bolting it on at the end. Two additions belong on that list as at September 2026. Code written with AI assistance is reviewed as unfamiliar third-party code, not as your own, because the failure mode is confident, plausible code carrying an old pattern or a hallucinated dependency; and where a model is part of the application, the model, its weights, its adapters and its serialisation format are supply chain components with the same provenance questions as any other dependency. A web application firewall (WAF) sits in front of an application and filters common attacks, which is a useful layer but a supplement to fixing the code, not a substitute for it.

Web testing is easy to practise safely because the field has built deliberately vulnerable applications for exactly this purpose, so there is never a reason to test a site you do not own. The unit's own lab runs Kali Linux (carrying Burp, ZAP, Nikto, sqlmap and the rest) as the testing machine against the xVWA vulnerable application and a pair of practice targets on an isolated virtual network. The wider set of practice targets is worth knowing: the Damn Vulnerable Web Application (DVWA) is a classic local target; OWASP Juice Shop is a modern, deliberately insecure application that maps its challenges to the Top 10; and OWASP WebGoat is a guided teaching application. Run any of these as a virtual machine or container on an isolated network. For structured practice without any local setup, the PortSwigger Web Security Academy (portswigger.net/web-security) is free, made by the authors of Burp Suite, and covers every vulnerability in this unit with hands-on labs; it is the single best companion to this page.

For the AI material, the same principle applies and the same kind of target exists. OWASP maintains a Vulnerable Web Applications Directory, which now lists deliberately vulnerable model applications alongside the traditional ones; the Damn Vulnerable LLM Agent is a chatbot built on a LangChain ReAct agent specifically for practising prompt injection against an agent's reasoning loop, and it runs locally under Streamlit or Docker against a hosted or local model. Practise prompt injection there, or on a model feature you have built yourself, and nowhere else; a production chatbot belongs to somebody, and Part 10.7 of the Criminal Code does not carve out an exception for text.

These notes were built for personal professional development from current, authoritative sources rather than transcribed from the training package. The unit scope, elements, performance criteria, knowledge evidence and assessment structure are taken from the VU23222 Assessor Guide (v4.8, AQ&I October 2025, held in the vault); the elective placement, nominal hours (40) and assessment conditions, including the named OWASP Secure Headers Project resource, are confirmed against the CDU TAFE course document for 22603VIC Certificate IV in Cyber Security (V001, held in the vault); and the unit description follows the Victoria University published unit page for VU23222 (vu.edu.au), read August 2026 with no page-modified date shown. The web-risk material is grounded in the OWASP Foundation's own resources: the OWASP Top 10 2025 (owasp.org/Top10/2025, finalised November 2025) alongside the 2021 list the syllabus uses, the Web Security Testing Guide, the Application Security Verification Standard, the Secure Headers Project (owasp.org/www-project-secure-headers/), the Cheat Sheet Series, and Juice Shop and WebGoat. Header, protocol and browser-control detail is cross-checked against the Mozilla Developer Network web security documentation (developer.mozilla.org) and the HTTP/2 and HTTP/3 specifications. Tool references come from each project's own documentation: Burp Suite and the PortSwigger Web Security Academy (portswigger.net), OWASP ZAP (zaproxy.org), Nikto, sqlmap, Nuclei, and the ffuf, gobuster and feroxbuster projects for content discovery, plus the BeEF project (beefproject.com). Web sources were read in August 2026; the SQLi, XSS, IDOR and session-attack mechanisms and the DIRB and BeEF status notes reflect current practice rather than a single dated page.

The artificial intelligence sections were added in September 2026 and rest on separate sources. The two lists come from the OWASP GenAI Security Project (genai.owasp.org): the GenAI LLM Top 10 2026, released 3 August 2026, with the ten entries taken from the project's own repository at github.com/GenAI-Security-Project/GenAI-LLM-Top10 rather than from secondary coverage, which was inconsistent on the ordering; and the Top 10 for Agentic Applications, released 9 December 2025 by the project's Agentic Security Initiative. Defensive guidance follows the OWASP LLM Prompt Injection Prevention Cheat Sheet. The vulnerability discovery material draws on the UK AI Security Institute's evaluation of Claude Mythos Preview, published 13 April 2026; Anthropic's own Project Glasswing initial update of 22 May 2026, which is the source of the discovery figures and is published by the organisation running the project; VulnCheck's analysis of the public CVE record, published 15 April 2026, which reaches a more limited conclusion about publicly attributable impact and is cited alongside it for that reason; and the Cloud Security Alliance research note on AI vulnerability disclosure velocity, published 24 May 2026, which is the source of the patching, CVE growth and time-to-exploitation figures. Prioritisation sources are the CISA Known Exploited Vulnerabilities catalogue and EPSS, maintained by the EPSS Special Interest Group at FIRST. Practice targets are from the OWASP Vulnerable Web Applications Directory. All read 2 September 2026.