[PHP-INTERNALS] short_open_tag

This is what the filter extension is for. You should be working withescaped data by default and only poke a hole in your data firewall inthe few places where you need to work with the raw data. Doing it theother way around is going to lead to all sorts of security issues.

Mhm. Isn't the the right paradigm to prepare variables at the time theyare passed into subsystems (sql, shell, html etc.)? So what do you meanwith "escaped data" here? html/xml escaped, sql escaped (which sqlsystem and which encoding?). Sounds a bit like magic_quotes reloaded*hides*

It is, but it is magic_quotes done right. You apply a really strictfilter that makes your data safe for display and your backend bydefault. The only place you can reliably do this this is at the pointthe data enters your system.

Input fitering has valid uses, but protecting html/sql/shell/etc.is not among them. Legitimate input like O'Reilly requires differenttreatments depending on html/sql/shell/etc. context. It would beincorrect to always insert a \, it would be incorrect to alwaysremove the ', and it would be incorrect to always reject the input.

You can also choose to never store the raw single quote and always workwith encoded data. Or, as I suggest, always filter it by default and inthe places where you want the raw quote back or you want it filtered fora specific use, specify explicitly which filter you want to apply. Itis the data firewall approach. Filter everything by default with anextremely strict filter and poke holes in your data firewall asnecessary. It also makes it easy to audit your code because you onlyhave to track look at the places where you have poked a hole.

Data flow control (a.k.a. taint support) can detect when outputisn't converted with the proper conversion function. This can bedone in reporting mode (my approach) or it can be done in "automaticfixing" mode (other people). These different approaches makedifferent trade-offs between programmer effort and system overhead,and avoid the data corruption that input filtering would introduce.

Having to do active checks on each use is extremely expensive. You saidyourself you suggest only enabling this during development. The datafirewall approach isn't actually all that different from the taintapproach. The big win is that there is no runtime checking necessaryand thus no performance hit.