And the template engine offered no alternative, no protection, and no management of that risk. Despite offering to execute data as code by default. Its default behavior has risk, and there is no direct solution offered by the template engine.
This is where I jump off the bandwagon... There are at least two separate risks being mentioned so far - user input, and PHP code in templates.
The first has nothing to do with a template engine flaw or error. The input should be filtered and escaped by the developer - they know the data, they determine what requires escaping. Yes, the template engine could hande this within the templates (giving the designer a say), and yay, it can. The "escape" modifier. Personally I prefer doing it manually, I pretty much escape everything without exception in the basis allowing exceptions allows mistakes.
The first ignores other potential sources of danger.
Name one, and provide an example (well, if PJ has no objections). This is unrelated to the originally posted "flaw".
And the template engine offered no alternative, no protection, and no management of that risk. Despite offering to execute data as code by default. Its default behavior has risk, and there is no direct solution offered by the template engine.
We really need to fine grain this whole debate... It's getting murky.
Risk 1: Template contains malicious code. Right?
Now where is the risk generated? The author of the template. The template engine cannot be the risk generator since it has been deemed to have no responsibility for screening PHP code within a template - it's blunt and true - it does not care. This is a documented difference from Smarty. The logical conclusion is that if an application developer fails to implement a method to mitigate any such risk, they have failed in securing their application. It's their job. Yes, it COULD be the template engine's job - but it's not. It parses, it compiles, it generates - the rest is not in its job description. It does its documented job - you can't blame it when it's accused of failing to do something. It'll just pull out its job description and throw a two finger salute.
It is not a Template Engine's job to second guess the developer - unless the developer wishes to be second guessed. Or have someone second guessed. For this very reason, Smarty is distributed with the security feature (feature - not required security) disabled by default. What you are claiming is that PHP in a template is wrong - more or less.
This is just plain wrong.
And with the principle of defense in depth, with the Smarty security features in place, its wouldn't cause a failure at the template engine layer. Thats a flaw in the template engine! Just because you can alternatively avoid the problem with { good admins, trusted templates, different template engines}, doesn't change the fact that it IS a flaw at the template engine level.
Your first sentence is entirely correct. The Smarty feature is a perfect example of defense in depth. However, such a measure should in most circumstances remain a redundant measure, as in never required. If I write a Template, with no PHP code, and use the Template-Lite library, and distribute my application - I fully expect such a feature NEVER TO BE REQUIRED. Having it would be a comfort blanket only. Pointless. I already have multiple layers protecting template use.
Such a measure does become a requirement (not simply a defense in depth measure) when the risk of a contaminated template being introduced into a system increases. Suddenly the template is out of my control, I'm not writing it, I'm not reviewing it, some guy down the road did. Using TL then would be crazy talk.
You could (and you seem to be) go so far down the paranoid street that you distrust the developers of an app and make it a requirement. What you're missing is that most of us assess that risk as negligible. If something goes wrong within the ranks of a project, I strongly doubt our templates are the hotspots.