3 ms·
I think "parse, don't validate" is an improvement on what the author of this article recommends: « So in cases where you do need to “echo” raw user input, care
by mjw1007 5y ago
I think "parse, don't validate" is an improvement on what the author of this article recommends:
« So in cases where you do need to “echo” raw user input, carefully filter input based on a restrictive whitelist, and store the result in the database. When you come to output it, output it as stored without escaping. »
I think the "parse, don't validate" approach comes out as follows:
- take the list of things you would have included on your whitelist
- add nodes for them to your internal representation for parsed markdown
- extend your markdown parser to convert html-like input into those nodes
- implement output for those nodes in a similar way to normal markdown
This way, given the "escape output" they recommend, it's harder for any variant of the input that you hadn't considered to have harmful effects.
- yakshaving_jgt 5y agoNo, the parse, don’t validate idea is completely unrelated. It’s about leveraging a type system like in Haskell. It’s about parsing a value into a type with a narrower domain which in turn minimises the amount of control flow needed to implement a sufficiently correct program.
- mjw1007 5y agoI agree with "It’s about parsing a value into a type with a narrower domain", but I don't see how you get to the first sentence. In their example of a markdown renderer, the internal-representation node is the type with the narrower domain.