Secure-by-Default Templating in Robot Framework / RPA
Enabling Jinja2 autoescaping by default for HTML and XML templates in robotframework-templateddata: closing a cross-site scripting (XSS) class in low-code/RPA automations by making safe output encoding the default.
This is the sibling of the secure-by-design SQL work: the same goal, close an injection class at the library level, here taken one step further. Where the SQL work could only add a safe path alongside the unsafe default, this library let me flip the default outright. Where that project closed SQL injection in the database keyword, this one closes cross-site scripting (XSS) in templated output.
The vulnerability
robotframework-templateddata is a Robot Framework library for generating data from Jinja2 templates. Jinja2 ships with autoescaping off by default, so a template that renders untrusted data into an .html or .xml file passes characters like <, >, and & straight through. The moment a citizen developer interpolates user-controlled data into an HTML document, that’s a stored/reflected XSS waiting to fire, with no warning that the default was unsafe.
The redesign - autoescaping by default
The PR (#7) flips the default for the file types where it matters: autoescaping is enabled by default for .html and .xml templates, so dangerous characters are converted to safe entities automatically. This follows the OWASP XSS Prevention Cheat Sheet’s Output Encoding strategy, the primary defense against XSS, applied at the library level rather than left to each automation author to remember.
Authors who genuinely need raw output can still opt out per-template using Jinja2’s built-in override mechanisms, so the change is safe-by-default without being a dead end. The PR shipped with two test cases (one proving autoescaping is active, one proving the override still works), and was reviewed, merged, and released by the maintainer.
Why it matters
Low-code and RPA tools hand powerful capabilities to people who were never the audience for “always encode your output.” When the library default is unsafe, every automation built on it inherits the flaw silently. Flipping the default, building on the parameterized-query work that made the safe path idiomatic before it, makes the secure choice the path of least resistance, protecting downstream users who will never read the cheat sheet.