Tempest 3.0 Lands With PHP 8.5-Only and a CSRF Defense You Don't Have to Code

The PHP world has had two reliable answers to "what framework should I use?" for almost a decade — Laravel for full-stack, Symfony for enterprise. This week the question has a real third option, because Tempest 3.0 dropped on February 12 and the project has shipped three feature releases (3.0 → 3.2) in less than two months. If you have not heard of Tempest yet, here is the elevator pitch: it is a modern PHP framework that requires PHP 8.5 or higher, treats attributes as first-class routing, and aggressively drops boilerplate that other frameworks still ask you to write.

Three things in the 3.x line are worth your attention as a working PHP developer.

1. PHP 8.5 only — because the framework is built around new PHP features

Tempest 3.0 is the first major framework to set its floor at PHP 8.5. That sounds aggressive, but it is the reason the framework can do what it does. PHP 8.5 brings the pipe operator, the new array_first / array_last functions, persistent attributes, and long-awaited improvements to enums and readonly classes. Tempest's controllers, console commands, and event handlers are all defined with attributes that read like a clean DSL, and every line of that DSL exists because PHP 8.5 finally lets it.

2. CSRF protection moved from token to two headers

This is the change I find most interesting from a real-world security standpoint. The classic anti-CSRF token approach (hidden form input plus middleware that compares it with the session) is well-understood but brittle: AJAX SPAs forget to attach it, mobile apps hard-code it, and everybody eventually adds an "exempt this route" flag. Tempest 3.0 removes the <x-csrf /> element entirely and replaces the workflow with checks against the Sec-Fetch-Site and Sec-Fetch-Mode HTTP headers, which modern browsers attach automatically. A same-origin POST carries Sec-Fetch-Site: same-origin and is allowed; a cross-origin attack carries same-site or cross-site and is rejected. It is closer to native browser semantics than to a framework token.

3. PHP-to-TypeScript interface generation

On February 20 the project shipped a generator that walks Tempest's domain classes and emits TypeScript interfaces. This sounds boring until you have spent six months watching your front-end and back-end DTOs drift apart. With Tempest, you change the PHP class, run one console command, and your React / Vue / Svelte client gets the new shape. Combined with March's HasOneThrough / BelongsToMany ORM additions, source-map view debugging, and UUID primary-key support, the framework is closing the practical gap with Laravel.

What this means for you

If you are starting a new SaaS or content site this quarter and your team is comfortable on PHP 8.5, Tempest is now genuinely production-viable for a small-to-medium project. If you maintain a Laravel codebase, Tempest is not a "switch tomorrow" — it is signal. Two of its choices (attribute-based routing as default, Sec-Fetch-* as the CSRF gate) are good enough that the bigger frameworks will start integrating them.

My Take

PHP frameworks have been "Laravel + everyone else" for a very long time, and that monoculture is part of why the language feels less exciting to outsiders than it should. Tempest is the most credible attempt I have seen to use new PHP versions as a real differentiator instead of just a changelog checkbox. The Sec-Fetch-* CSRF approach in particular is the kind of decision that gets copied — it is simpler, harder to misconfigure, and aligns with where the browser platform is going. Even if you do not adopt Tempest, you should adopt that pattern.