Skip to content
tezvyn:

Design a secure templating engine for user notifications

Source: Wikipedia: Template processorHardHow cards are made

Design a secure templating engine for user notifications

Tests balancing creator flexibility with defense-in-depth security and i18n. Strong answers cover context-aware auto-escaping, a restricted AST grammar, ICU MessageFormat for pluralization, and sandboxed execution.

What's really being asked

This question evaluates whether you can design a domain-specific language and runtime that gives content creators expressive power while maintaining strict security and grammatical correctness across languages. Interviewers want to see defense-in-depth, not just a single sanitization step.

The full answer

First, parsing strategy: use a formal grammar and generate an abstract syntax tree rather than regex substitution, because regex fails on nested conditionals and enables injection. Second, security layers: context-aware auto-escaping where the engine knows whether the output target is HTML email, plain text push, or JSON, and applies the correct encoder for that context. Third, logic primitives: restrict the AST to a whitelist of nodes like variable interpolation, if-else, and ICU MessageFormat selectors for pluralization and gender, rather than exposing general-purpose scripting. Fourth, execution sandbox: run template rendering inside a sandbox with CPU time limits, memory caps, and a denylist of system calls to prevent denial of service from infinite loops or recursion. Fifth, internationalization: integrate CLDR data or ICU MessageFormat so translators can handle complex plural rules like Polish or Arabic without engineering changes.

The mistakes people make

Suggesting that HTML sanitization on the final string is enough, because that ignores other contexts like SMS or JSON payloads. Proposing to let content authors write raw JavaScript or Python inside templates for flexibility. Using simple string replacement for variables, which breaks when translators reorder words or when user input contains reserved characters. Ignoring locale-specific plural forms and assuming every language uses one versus many.

What usually comes next

How would you handle user-generated templates from untrusted creators rather than just internal staff? What changes if the output channel is a mobile push notification versus an HTML email? How do you cache rendered templates without leaking data across users? How would you version templates and roll back a bad change instantly?

A concrete example

Imagine a ride-sharing app sending a receipt. A content creator writes a template that says "You took {count} ride(s) and saved {amount}." The engine parses this into an AST, validates that only allowed variables appear, replaces count with an ICU plural selector that renders "1 ride" or "2 rides" based on English rules but switches to Polish paucal forms for pl locales, escapes amount into HTML entities for email but leaves it unescaped for push, and renders the whole tree inside a sandbox that aborts if execution exceeds ten milliseconds.

Interview question

Which layered approach best secures a multi-channel notification templating engine?

  • a.Regex-based parsing with final HTML sanitization and raw scripting support for flexibility
  • b.Formal AST grammar with context-aware auto-escaping and sandboxed rendering with resource limitsCorrect
  • c.String replacement with input validation and HTML entity encoding for all outputs
  • d.Grammar-based parsing with output-side HTML sanitization and trusted internal execution
Why?

Option B is correct because defense-in-depth requires an AST whitelist to prevent injection, context-aware escaping tailored to each output channel, and sandboxed execution with resource limits. Option D is tempting because formal parsing is correct, but output-side HTML sanitization alone fails for SMS or JSON contexts and lacks sandboxing against DoS.

Just read this? Test yourself on what you have been reading.

Read the original → en.wikipedia.org

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.

See open roles