Background
So in summary. If you find yourself reaching for the |raw filter, stop. Instead lean on ProcessedText and pass a format, either one you define or one that the users chooses. Or failing that, use ['#markup' => ...].And in reaching for |raw you’re most likely opening an XSS vector.Perhaps for some homework, go and check your themes and make sure you don’t have any use of raw. Remember to follow the procedure for reporting a security issue if you find anything in a theme with security team support.Not surprisingly security advisories for Cross Site Scripting (XSS) were the the number one vector in Drupal contrib security advisories for Drupal 7 and below.
Using raw bypasses Twig’s protection
Check the type of the field. If its in the Text family, e.g. Text, Text (long), Text (long, with summary). You should instead be using the processed property – $node->field_body->processed. This has already been sanitized and is flagged as safe to Twig. Anything flagged as safe bypasses auto-escaping.But there are very few cases where this is the correct approach.Which brings us to using the |raw filter. When you use it you’re saying to Twig – actually, don’t auto-escape this variable, I know better.
What to use instead
If you’re using Drupal’s field formatters, you’re unlikely to get into this scenario. The most likely cause is you’re accessing raw field values.If you’re looking at a template and you’re finding that a variable is being double-escaped. E.g. instead of Mathematics & Data Science you’re seeing Mathematics & Data Science you might be tempted to reach for raw to fix it.Instead you need to examine where the value is coming from.This meant remembering to call check_plain or check_markup in preprocessing hooks on every variable.If you’re doing something custom, like in a configuration form or similar, lean on the TextFormat form element – '#type' => 'text_format'. This gives you a value and format pair. You can use this with the '#type' => 'processed_text'render element and again, the returned value is already marked as safe.E.g. something like $node->field_body->value in either a preprocessing hook or some ungainly Twig expression {{ node.field_body[0].value }}.The release of Drupal 8 saw the adoption of Twig as the default templating engine. With auto-escaping by default, Twig promised to provide enhanced security against XSS vectors. No more needing to remember to call check_plain or check_markup – any variable available to Twig was escaped on output!
So before you reach for |raw
Let’s cast our minds back to Drupal 7. A time before twig. We had .tpl.php templates with PHP template as the default templating engine. Every variable available in your template had to be carefully sanitized before being printed to avoid XSS.Failing that, if you want a limited set of HTML tags to be allowed and don’t have a filter format to use with the ProcessedText element, you can use a #markup render array. E.g instead of printing a string, use ['#markup' => $the_string] – this will go via Xss::filter with the admin tags list. It will allow through some tags, but will strip out those that can lead to XSS.
