What does HTML embedded through the srcdoc attribute mean?
An iframe srcdoc attribute can contain the markup of a document directly, and the browser parses that value as HTML inside the frame. This differs from an ordinary paragraph, link, or image in a description: the product field stores an embedded document with its own markup and rendering context.
MDN treats srcdoc as an injection sink when it receives untrusted strings and explains the importance of sandboxing, CSP, and Trusted Types. The PROVEN detector flags the construct in catalog data; it does not claim the data came from an attacker, that the frame ran without a sandbox, or that the store is compromised.
Examples of embedded content that must be understood before remediation
These fictional examples omit executable code. They show possible uses of srcdoc, do not demonstrate a vulnerability, and do not define the actual iframe configuration in your store.
<iframe srcdoc="<p>Instructions</p>"></iframe>[HTML document included directly in the attribute]Even static content changes description structure; review whether an iframe is needed or ordinary rich text can represent the information.
A migrated widget keeps an iframe with srcdocCheck whether the widget is still supported and sandboxedThe origin may be legitimate, while current configuration and usefulness still require separate review.
Promotional content is stored as an inline document in the descriptionCompare with a theme section or ordinary rich textA more maintainable alternative may exist without embedding a document in the product field.
What does PROVEN check?
Checks content forms that embed a document or fragment directly inside the description.
Why does it matter?
Embedded content can carry structure and behavior separate from ordinary description text.
Why is srcdoc different from ordinary description HTML?
srcdoc is more than formatting: the browser parses its value as the iframe document. MDN also explains that the relationship with the parent document depends on sandboxing and related policies. That makes the finding worthy of more technical review than an ordinary formatting tag.
For the merchant, the question is whether the embedded function is still needed and where it should be managed. PROVEN does not treat this page as a vulnerability scanner and does not conclude that the presence of srcdoc means exploitation.
What can PROVEN do?
PROVEN can prepare controlled removal of the embedded element; the case must be reviewed before application.
How PROVEN handles an iframe using srcdoc
The flow identifies the embedded document, reviews its purpose, and avoids automatically converting it into a different content type.
- Locate the iframe and srcdocPROVEN preserves the attribute and product context as evidence without executing the markup to infer intent.
- Review purpose and protectionsThe merchant determines whether the iframe is still needed and whether sandboxing, CSP, and implementation belong to a supported component.
- Prepare removal only when function is clearIf the embedded document is residue, PROVEN can prepare removal; if the function is legitimate, migration requires a reviewed technical solution.
Why does srcdoc need technical review?
Removing an iframe can remove information or functionality. Keeping it without understanding sandboxing and provenance can also preserve a hard-to-maintain surface.
The finding does not prove that srcdoc markup is untrusted or exploitable. A security conclusion requires evidence about source, policies, and execution context.
What this page does not tell you
- The detector flags the srcdoc construct; it does not execute the document to prove behavior.
- The finding does not prove the iframe lacks a sandbox or that attacker-controlled data reaches it.
- The presence of srcdoc does not prove XSS, attack, or store compromise.
- PROVEN does not automatically design a theme or app replacement for a legitimate embed.
- CSP, sandboxing, and Trusted Types are separate controls that must be evaluated in real context.
Frequently asked questions
What does srcdoc do?
MDN explains that srcdoc sets inline HTML markup for an iframe document and the browser parses the value as HTML.
Is srcdoc always vulnerable?
No. Risk depends on data provenance, sandboxing, CSP, and other controls; attribute presence is not evidence of exploitation.
Can PROVEN convert the iframe into text?
Not automatically. Conversion can lose function, layout, or content, so the merchant needs to decide the intended result.
Why is this a catalog-quality detector?
Because the attribute is stored in product-description content and can be inventoried and reviewed as catalog hygiene without pretending the detector is a security assessment.
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 — iframe srcdoc propertyMDN explains srcdoc parsing and security considerations around untrusted content, sandboxing, and Trusted Types.
- Shopify — Using the rich text editorShopify documents rich-text HTML and automatic filtering intended to prevent problems.
- MDN — Content Security PolicyMDN describes CSP as a separate mechanism for restricting resources and executable content.