On Tue, Dec 23, 2025 at 12:30 PM Sergei Issaev <[email protected]> wrote:
> > Yes, h() works — and many projects already define it. But that’s exactly > the problem: everyone reinvents it, often with slightly different flags, > encoding assumptions, or error handling. This leads to: > - Inconsistent escaping across projects or even within the same codebase. > - Junior developers skipping escaping because “it’s not built in”. > - Security relying on project-specific conventions rather than > language-level defaults. > > By providing a standard, secure-by-default output tag in core, PHP would: > - Reduce boilerplate. > - Encourage safer habits out of the box. > - Give small projects (e.g., WordPress plugins, scripts, internal tools) > a zero-dependency way to escape safely — without requiring them to > define or remember h(). I can relate to these pain points, but I also think your conclusions are a bit of wishful thinking. Junior developers would still not use it, because they'd need to know it first - just like h(). Even seasoned developers would avoid it because many will deem the syntax to be ugly, and the solution imperfect. And security gets a band-aid instead of proper protection, which is more dangerous than you'd think - I've seen it time and time again, some feature offers limited security benefits, people only care to remember that "it's secure", use it for everything without critical thought, and you end up with masses of developers believing that they write secure code when it's not even close to that. Then PHP has to take the blame for providing insecure XSS escaping. Cheers, Andrey.
