If you're going with a DSL anyway, making that language happen to look like a strictly-defined subset of HTML doesn't necessarily reduce its security (plus it a

If you're going with a DSL anyway, making that language happen to look like a strictly-defined subset of HTML doesn't necessarily reduce its security (plus it allows for a WYSIWYG editor option). But too often what happens next on the back end is an attempt to "sanitize" that input in place and output whatever's left, rather than to fully parse it. That just leads to an arms race between sanitizers and XSS exploiters. Instead, parse the HTML just as you'd have to with BBCode or Markdown. Store it in an internal representation that's only capable of the minimum needed formatting features. (There's no actual HTML left at this stage. It's equivalent to any other DSL.) Then render HTML out of that parse tree, so that every bit of user input is HTML entity-encoded, and everything else (tags and attributes) comes from constants in the program. This can be even more secure than regexp-based DSL translators that build up a result from input in multiple passes, since they tend to lack such a well-defined separation between input text and output HTML.