3 ms·
There are multiple approaches here. You could escape late like with htmlspecialchars(), or build it into the framework (recursively filter all POST/GET input fo
by aussieguy1234 4y ago
There are multiple approaches here. You could escape late like with htmlspecialchars(), or build it into the framework (recursively filter all POST/GET input for example). You can do it in the controller with filter_input etc...
But in the end, it doesn't need to be a part of the framework, I'd like to leave it up to the developers to decide on how it makes sense for them to do input filtering/output escaping based on their own requirements.
There are some cases where you wouldn't want to aggressively filter everything, for example I've worked on apps in the past that allow HTML for certain things. Turning on filtering would prevent that (although there are ways to allow/disallow certain tags).
- lucideer 4y ago> recursively filter all POST/GET input for example). You can do it in the controller with filter_input etc... This is what many do and it's extremely bad practice. I wrote a pretty detailed comment here on HN explaining this before but can't find it easily now so here's a similar looking article I found instead: https://benhoyt.com/writings/dont-sanitize-do-escape/ https://benhoyt.com/writings/dont-sanitize-do-escape/ it doesn't need to be a part of the framework, I'd like to leave it up to the developers You're right, "need" is a strong word, it's a suggestion for a useful feature. Leaving it up to developers does in practice tend to lead to insecure code most of the time though: it can sometimes be nice to help developers write better apps. If you need raw html output the best approach is to batch DOMSanitize it and cache it to be served raw: in these cases it's usually an exception so turning output escaping off for 1 or 2 exceptions isn't a huge ask (and focused the scope of your attack surface area when you're auditing).