Hi internals,
I’d like to propose a small but security-relevant addition to PHP’s
templating syntax: a new short echo tag that automatically applies
secure HTML escaping.
**The problem**
Despite PHP being a perfectly capable templating language on its own,
developers often reach for external templating engines (like Twig or
Blade) primarily to get automatic HTML escaping and avoid XSS. This adds
dependencies, complexity, and performance overhead — even when 95% of
the project would be simpler with native PHP templates.
At the same time, manual escaping is error-prone:
```
<?= $user_input ?> // ❌ dangerous
<?= htmlspecialchars($user_input, ENT_QUOTES | ENT_HTML5, 'UTF-8') ?>
// ✅ but verbose
```
Many security vulnerabilities stem from the sheer verbosity of the safe
version.
**The proposal**
Introduce a new short echo tag:
```
<?~ $expr ?>
```
which compiles to:
```
<?php echo htmlspecialchars($expr, ENT_QUOTES | ENT_SUBSTITUTE |
ENT_HTML5, 'UTF-8'); ?>
```
Key points:
- Uses htmlspecialchars() (not htmlentities()) — sufficient and standard
for XSS prevention.
- Hardcodes secure flags and UTF-8 encoding (aligned with default_charset).
- Syntax is currently a parse error → no BC break.
- The <?~ tag is available whenever <?= is available.
This gives native PHP templates a secure-by-default output mechanism
without requiring a full templating engine.
**Why not just use Twig/Blade?**
There’s nothing wrong with those engines — **but PHP itself is already a
great template language**. Requiring a separate dependency just for
auto-escaping feels like overkill for many projects (e.g., small apps,
WordPress plugins, legacy modernisation).
**About implementation**
I’m not a C developer and don’t have experience with the Zend Engine
internals. However, I’m fully committed to:
- Writing and maintaining a complete RFC document
- Participating actively in design discussions (syntax, flags, security
model)
- Testing any implementation or prototype
- Collaborating with anyone willing to help with the parser/lexer patch
If the idea gains support, I hope a volunteer from the internals team
might be interested in guiding or contributing the low-level implementation.
**Next steps**
I’d appreciate your thoughts — especially on:
- Whether this functionality belongs in core
- Security assumptions (e.g., hardcoded UTF-8, flag choices)
- Syntax alternatives (<?~ vs <?h= vs others)
Thank you for your time and consideration.
Best regards,
Sergei Issaev
