Template Directives v26.9+

Hi {{var customer.name}},
your order {{var order.increment_id}} has shipped.

{{var order.getBillingAddress().format('html')}}

{{if order.getIsNotVirtual()}}
  Your tracking number is {{var shipment.getTrackingNumber()}}.
{{else}}
  Your download is ready in your customer account.
{{/if}}

{{depend comment}}
  Note from the merchant: {{var comment}}
{{/depend}}

{{if order.grand_total > 100 && customer.group_id == 2}}
  Thanks for the big wholesale order!
{{/if}}

{{if order.status in ['complete', 'closed']}}...{{/if}}

{{if customer.getName() starts with 'Dr.'}}...{{/if}}

{{template config_path="design/email/header"}}
...
{{template config_path="design/email/footer"}}

$object->setData('content', Mage::getSingleton('core/input_filter_maliciousCode')
    ->filterPreservingDirectives($object->getData('content'), false,
        Mage::helper('cms')->getPageTemplateProcessor()));

The masking pattern is a security boundary

Whatever the masking pattern in Mage_Core_Model_Input_Filter_MaliciousCode matches is restored without sanitization. That makes it much stricter than the renderer's own CONSTRUCTION_PATTERN. It enforces three rules:

1. The keyword must be one the supplied processor actually resolves.
2. The body must consist of well-formed name="value" parameters.
3. No parameter may be named like an event handler (on followed by letters).

Rule 1 matters because a renderer leaves a directive it has no handler for untouched in the output. Masking such a directive would hand the payload straight to the browser.

Rule 2 matters because excluding < and > is not enough on its own. An HTML attribute is terminated by a quote, so a body like " onerror="alert(1) grafts a live event handler onto the enclosing tag without using an angle bracket at all.

Rule 3 is why the first two are not enough. A well-formed parameter is also a well-formed HTML attribute, so {{media url="a" onerror="alert(1)"}} satisfies both: media is a keyword the processor resolves, and the body parses. Emitted verbatim inside alt="…", the HTML parser ends the attribute at the directive's first quote and reads onerror as the next attribute of the tag. Resolving the directive discards the extra parameter, so this only bites on a render path that emits rather than resolves — excluding the name keeps the preserved text inert either way. Only on plus letters is rejected, so a widget parameter such as on_sale still masks.

The exclusion deliberately stops at event handlers rather than growing to cover href, src and friends, which the same trick can also graft onto the tag. Rejecting on plus letters costs nothing, since no directive parameter is ever named onclick, whereas href and src are plausible widget parameter names, so excluding them would stop masking a legitimate directive and mangle it on save. What keeps those inert is the invariant at the end of this box: every handler reads its own named parameters and drops the rest, or stripDirectives() removes the construction. Preserve that invariant on new render paths instead of extending this list.

Whether the renderer runs at all counts too. Catalog descriptions reach the template processor only when Allow Dynamic Media URLs in Products and Categories (catalog/frontend/parse_url_directives) is enabled, and that setting is per store view. Deciding it at save time would be wrong twice over: the flag can be switched off long after the save, and it is per store while the stored value is shared. So the save keeps the directive intact, and Mage_Catalog_Helper_Output calls stripDirectives() when the rendering store will not resolve it. Nothing is lost, since a directive that is never parsed would not have worked anyway.

That fallback is keyed off is_wysiwyg_enabled alone, deliberately, because that is the flag the save side masks on. An attribute with WYSIWYG enabled but Allow HTML Tags on Frontend disabled would otherwise match none of the three branches — neither escaped, nor resolved, nor stripped — and its directives would reach the page exactly as authored.

No processor means no preservation. If you cannot name the processor that will resolve a directive, there isn't one. Masking on the assumption that something downstream will resolve it is how content ends up shipping a live event handler. Product alert emails are the worked example: their markup is echoed into an already-rendered {{var alertGrid}}, which the template filter does not rescan, so they strip directives and filter as plain HTML.

{{var}}, {{depend}} and {{if}} are never masked, even though every processor implements them. With no template variables assigned, which is precisely the CMS and catalog case, they render verbatim. The invariant to preserve: a masked directive must always resolve at render time and never reach the browser as authored.

What sanitization removes

Mage_Core_Helper_Purifier sanitizes with Symfony's HTML sanitizer on the W3C Sanitizer API baseline, which is HTML5-native. video, audio, source, picture, figure, details, section, article, mark and time all survive a save, as do id, class, style, target, rel, loading, srcset and any data-* attribute. Removed:

Input	After save
<script>, <iframe> (Vimeo and other embeds, maps), <object>, <embed>	removed with contents
<form>, <input>, <select>, <textarea>	removed with contents
data: URIs in a media src	dropped
event handler attributes (onclick, onerror, ...)	dropped

YouTube embeds have the widget above as a replacement. To put a form on a page, use a block or a widget rather than markup in a content field: a form in stored content posts wherever its action says, under the merchant's own domain and certificate.

class and style are kept even though the W3C baseline classes them as unsafe, because the WYSIWYG preserves both and stores text alignment as inline style. The sanitizer does not parse CSS, so the CSS-level vectors (expression(), behavior:, javascript:) are removed by the regex pass in Mage_Core_Model_Input_Filter_MaliciousCode, which runs first.

data-* needs a word of explanation, because the sanitizer matches allowed attributes by exact name and has no wildcard for them. allowAttribute('data-attr', '*') allows an attribute literally called data-attr on every element; it does not allow data-role. Since merchants put arbitrary data attributes on CMS markup, an enumerated list would always be incomplete, so Mage_Core_Helper_Purifier reads the data-* names off the content being sanitized and allows those. They are inert by definition, and the surrounding policy still applies, so a data-* allowance cannot smuggle an event handler through.

Stored content is only affected when the entity is next saved, so existing pages keep working until someone edits them. To adjust the policy, change Mage_Core_Helper_Purifier::buildConfig() rather than skipping sanitization at the call site.