Why does an onclick, onerror, or onload attribute deserve review in a description?
HTML supports event-handler attributes such as onclick, onerror, and onload, and the attribute value is treated as JavaScript associated with the event. MDN discourages these attributes and notes that CSP can block inline JavaScript. In a field intended for product description content, they introduce event logic where ordinary information and formatting are expected.
The detector looks for the observed attribute; it does not execute the code or claim that the handler ran. An attribute can be residue from a snippet, old widget, or migration. Its presence does not prove an attack, XSS, or store compromise.
Examples of inline logic attached to elements
These fictional examples show syntax at a conceptual level. They are not exploitation instructions and do not show that a browser or Shopify theme executed the fragment.
<img onerror="…">[handler associated with a load error]The finding identifies onerror; review its origin and remove the logic if it has no legitimate role.
<a onclick="…">Details</a>[inline action on click]A description link should have an intentional destination and behavior; review separates legitimate function from residue.
<div onload="…">…</div> in a migrated snippet[logic attached to imported markup]Check whether the snippet is still supported by the current theme before remediation.
What does PROVEN check?
Checks for information attached to elements that can trigger actions directly from the description.
Why does it matter?
Actions attached to content can introduce executable behavior into a field intended for description text.
What operational risk do inline handlers create?
The attribute mixes description markup with JavaScript logic, making catalog content harder to maintain and reason about. MDN recommends separate event listeners, while CSP treats event-handler attributes as inline JavaScript that restrictive policies block by default.
For a merchant, the goal is to know where such attributes exist and whether they belong to a supported function. PROVEN does not promise security from merely deleting a handler and does not turn the finding into a claim that an incident occurred.
What can PROVEN do?
PROVEN can prepare controlled removal of these actions; the change requires your review before application.
How PROVEN handles event-handler attributes
The flow isolates the attribute, apparent function, and alternative before any removal.
- Locate the on* attributePROVEN shows the element and attribute matching the rule, preserving the value as evidence without executing it.
- Review intended functionThe merchant determines whether the handler belongs to a widget, migration, or fragment with no current role.
- Remove inline logic under reviewIf the function is unnecessary, PROVEN can prepare attribute removal; if it is needed, it belongs in a supported implementation rather than being invented inside the description.
What should be checked before removing the handler?
Confirm whether the element has legitimate interaction and where that interaction should live in the responsible theme or application. Removing the attribute can change visible behavior.
Do not infer intent from code or assume the attribute executed. The finding alone is not evidence of attack, exploitation, or compromise.
What this page does not tell you
- The detector observes event attributes; it does not execute code or prove that a handler ran.
- The presence of an on* attribute does not prove XSS, attack, or store compromise.
- CSP and sanitization are separate controls that can block or remove inline JavaScript.
- A legitimate function should be reimplemented in the proper layer rather than lost through blind deletion.
- Examples are illustrative and are not payloads from your catalog.
Frequently asked questions
What is an event-handler attribute?
It is an HTML attribute such as onclick or onerror whose value defines code associated with an event. MDN discourages this inline JavaScript model.
Can CSP block inline event handlers?
Yes. MDN documents that restrictive CSP blocks inline JavaScript forms including event-handler attributes unless explicitly relaxed.
Does this mean I have an XSS vulnerability?
Not automatically. Insertion context, sanitization, and actual control over the data are required for a security conclusion.
Can PROVEN automatically move the logic into my theme?
Not as part of this detector page. It can prepare controlled removal; legitimate UI behavior belongs in the responsible component or theme implementation.
Sources and independent context
The sources below explain the relevant platform or web standards. They provide context for interpretation but do not by themselves show that your store has this finding.
- MDN — HTML attributes and event handlersMDN explains that event-handler content attributes synthesize JavaScript functions and discourages their use.
- MDN — Content Security PolicyMDN explains that restrictive CSP blocks inline JavaScript, including on* event handlers, by default.
- Shopify — Using the rich text editorShopify documents HTML sanitization in rich text to prevent storefront problems and security risks.