19 ms·
1. XSS != SQL injection 2. Adding a bunch of bogus escaping routines isn't an excuse for an incredibly poorly conceived off language, or continuing using it in
by tannhaeuser 5y ago
1. XSS != SQL injection
2. Adding a bunch of bogus escaping routines isn't an excuse for an incredibly poorly conceived off language, or continuing using it in production in the presence of superior solutions.
In fact, I'd go so far as to say if you're selling PHP solutions/consulting in this century for apps managing ecommerce or any other kind of PII, you should demand your customer signs a liability waiver. If you can even disclaim liability for gross negligence in your jurisdiction, that is.
- bruce343434 5y agoWhat should php do then? What's the alternative language that handles this better?
- tannhaeuser 5y agoFor traditional PHP apps wishing to continue SSR and server-side templating, integrate HTML-aware templating (PHP has always been half there considering embedded PHP is using SGML processing instructions; it "just" needs to offer additional, more sophisticated, injection-free SGML entity-based mechanisms). For highly dynamical apps, consider porting to JavaScript on the client side, and use PHP only as a service backend language. That's what I understand newer PHP frameworks are doing; but this will only be attractive for migrating legacy PHP apps rather than bring new users.
- bruce343434 5y agoI don't see the upside to the effort of porting to js. You still have all of the same pittfalls. Yes, you can build a DOM with 20x the code and 1/20th the performance ... or you can just call htmlspeciachars() in php. Yup, security is tedious and you need to stay on your toes.