SPIP WAF: Web Application Firewall for SPIP

[maathieu]

@ursrig

SPIP has always been a special project for me. It was one of the project that was pitched to me, and in the end, it turned out true. That is is so stable. That it is so efficient. That it does not create unnecessary work for developers, to keep re-building websites after 2 years just because the CMS developers changed their mind (Drupal, Wordpress, and most new tools). This is the counter-current that makes SPIP difference, and a real advantage for all those who know it. We live in a world where everything is secure and stable. It has to be, to sell. But it’s usually not true. For SPIP, it’s true.

This summarizes also why I am still sticking with Spip for important projects, despite having experience with other CMSes. Maybe your testimony could be worth appearing in the next Spip Gazette ?

[ursrig (Urs Riggenbach)]

Thanks @maathieu and @JamesRezo

I just saw this:

Two days ago I’ve blocked some IPs manually, IPs of very stupid, probably vibe-coded AI crawlers. Some bots never seem to learn. You would think that after 10 000 requests returning a 403 Forbidden, they would stop! So, cheers to 1 000 000 requests blocked.

The HTTP 403 Forbidden client error response status code indicates that the server understood the request but refused to process it. This status is similar to 401, except that for 403 Forbidden responses, authenticating or re-authenticating makes no difference (403 Forbidden - HTTP | MDN)

Thanks to these bots we can do some nice load testing on this plugin… With the latest improvements on caching I can see my server is no longer busy to apologize for the crawler’s bad code.

It also means these bots run completely unsurveillanced, burning the carbon emissions of a small rainforest while re-ingesting the same page over and over again, probably to train the next AI model… : |

[klaus]

Argh, downtime continues. Now I moved contents of IMG outside of webroot an deactivated al javascript-heavy stuff - in fact I moves squelettes to a scratch folder outside the webroot.

In spip-log Iget a lot of

2026-05-08 13:22:30 our_server_ip (pid 323129) :Pub:ERREUR: fonction execute_pipeline_waf_custom_rules absente : pipeline desactive

and some

2026-05-08 13:22:32 52.0.63.151 (pid 323129) :Pub:ERREUR: fonction execute_pipeline_waf_custom_rules absente : pipeline desactive

last entry :

2026-05-08 13:28:46 220.181.108.174 (pid 323562) :Pub:ERREUR: fonction execute_pipeline_waf_custom_rules absente : pipeline desactive

any idea ?
thx !
:-)k++

[ursrig (Urs Riggenbach)]

Yes, I had noticed this issue a while back.
It should be fixed normally with v1.1.3.

Are you on 1.1.3? I’ve just released 1.1.4 with a series of dashboard performance improvements also.

[ursrig (Urs Riggenbach)]

Ah wait, this is a different from the issue with cron/genie. It’s an issue with the pipeline. I’ve added a quickfix that should disable the error, via v1.1.5, that should be installable via plugins.

I always had a custom rule active on my dev env, but when I removed it I didn’t get the same error. Maybe because I didn’t reload the plugins page.

Anyhow I just added a fix that the pipeline variable is never empty. I think that should take care of that error.

fix: ensure pipeline globals are always defined (0f5142ca) · Validations ·...

Also, refreshing the plugins page may help.

[ursrig (Urs Riggenbach)]

@klaus and @cerdic my first experimentation with a native PHP caching, without APCU, are very promising.

When OPcache is enabled, it seems reading PHP-arrays from disk are almost free. So I am updating the caching functions to use that.

OPcache should be enabled by default in PHP since… 5.5. So, this would make SPIP WAF work even on very cheap hostings.

Will keep you updated! @nicod will hopefully able to run a performance test on his side. I’ll let you know when it’s ready for testing!

[ursrig (Urs Riggenbach)]

Hi All!

I’ve released a version 1.2.0 will work on low-end hostings as well. No more APCU requirement!

Feedback/testing is very welcome. I will also roll it out on some of the cheaper hostings I have in use. Previously this wasn’t possible.

@nicod, v.1.2.0 is the latest if you want to run another performance test.

The old APCU-based behavor can be activated with

// switch to apcu cache 
// case sensitive. 
define('_WAF_CACHE_BACKEND', 'apcu');

if needed.

If you just update to 1.2.0, the new OPcache behavior is used and the APCU is just there for comparison. If it proves to be more efficient than APCU, we can fully remove APCU. If APCU is more efficient, we can use it when it’s there, and otherwise fall back to OPcache.

Bon weekend,
Urs

[JLuc]

@ursrig

When OPcache is enabled, it seems reading PHP-arrays from disk are almost free. So I am updating the caching functions to use that.

Direct use of cache space is almost free, but more caches create cache space saturation : both for APCU and PHP OPCache, space is limited and allready fully used.

As a consequence, any more use of this space will induce quicker flushes (with APCu, and i believe it’s the same for OpCache) or inability to create new caches.

Great when SpipWAF is quick with APCU or OPCache, but how does it impacts the other SPIP scripts and cache uses ? Should also be valued.

[JLuc]

BTW XRay XRay - Plugins SPIP is usefull a plugin to explore APCu cache uses for spip caches and others.

[ursrig (Urs Riggenbach)]

Thanks @JLuc, I’ve inspecte wiht Xray the APCU side and also inspected the OPcache side.
I’ve added a section with the stats to the dashboard so users can keep an eye on it. v1.2.1 released just now.

It looks good for me. I’ve only checked on 1 site but it’s using 9MB for of the OPcache for the PHP-Arrays. The rest of SPIP/PHP consumes 19MB. So it’s a significant increase, but manageable.

OPcache Stats

It’s posible to switch to APCU in mes_options.php with

define('_WAF_CACHE_BACKEND', 'apcu');

The APCU stats are:

I am doing some heavy lifting with APCU in another plugin. The WAF doesn’t consume more than a few MB.

To me this looks good.

[pierretux (Pierre KUHN)]

Hello Urs,

With the latest version and a page recalculation, I get this:

And my little brother is tracking the IPs.

I will place it in the area soon.

[epilibre (Gilles Vincent)]

Hi, where can we post tickets ? I may have found dead code in waf_tarpit_and_block():
waf_send_block_response() is called first and exits at L882. The if ($delay > 0 && function_exists('fastcgi_finish_request')) block and sleep() that follow are unreachable. The tarpit delay feature is silently non-functional.

[b_b]

@epilibre

Hi, where can we post tickets ?

Here Éléments de travail · spip-contrib-extensions / SPIP WAF · GitLab ? ^^

[epilibre (Gilles Vincent)]

@b_b

Here Éléments de travail · spip-contrib-extensions / SPIP WAF · GitLab ? ^^

Merci, je n’ai pas l’habitude de l’interface de gitlab

[ursrig (Urs Riggenbach)]

Hello Gilles @epilibre,
Thanks so much for signaling that. I’ve added a fix in the latest release.

The default delay is 0, and so the bug in case you had set _WAF_TARPIT_DELAY to e.g. 5s, it would not wait for 5s but close the connection immediately.

Now if you set _WAF_TARPIT_DELAY to 10, 10s are added before the request is closed.

The tarpit concept, to basically delay the bots for x seconds per malicious request, is something I had in mind at the beginning of the project but at least since @cerdic’s comment about DOS my thinking on it has changed.

Because it’s a double edged sword: It may delay bots, but it also may consume your connection pool and result in DOS. That’s why the default is 0. If you are serious about tarpit, I think it should be implemented at the proxy/webserver level, not PHP, to prevent risk of DOS.

So my recommendation is to not set _WAF_TARPIT_DELAY permanently. But it can be interesting to play with it to see if it slows down bots.