Web Application Firewall (WAF) via Spryker

Angel Albarracin

Please use this thread to post your questions in relation to WAF.

litzmann

Hello all. I will post the first question I suppose.

In the past, nearly all WAF changes that were requested by us (COLONS) from Spryker were because the WAF was blocking legitimate requests. Only once did we need to ADD a rule. You can have a look yourself by looking up Tickets 00051949, 00052129, 00052159, 00058404, 00058448 and 00062986 - those were the ones i found.

You can see that many of those are the same error happening on either multiple environments or re-appearing after some time. Mainly one of our endpoints that allows permission management for our customers got blocked; as well as the manifest.json getting blocked and basically rendering the shop unusable.

Now to be fair, all of these were resolved fairly quickly! And false positives do happen; thats all water under the bridge anyway. However Sprykers recent changes in communication around WAF topics has me very worried. Sentences like

"Customers and partners can request existing custom rules be deleted, but amendments will not be possible."

and

"Spryker has gladly assisted with ad hoc WAF customizations or feature requests, even though such amendments fall outside the scope of our standard service offering"

paint a picture in which Tickets that request WAF changes are denied outright.

So therefore I ask:

What is the plan for the future when dealing with false positives and allow listing endpoints and files? Will support be able to assist me in the same quick and professional manner as they did in the past? Or am I to expect troubles in such cases?

Thank you in advance!
Phillip from COLONS

Angel Albarracin

Hi Phillip,

Thank you for raising this - and for sharing the ticket history; it’s very helpful context. The recent messaging you’ve seen refers only to new custom WAF rules that fall outside our standard baseline service. It does not affect how we handle false positives.

If the baseline protection ever blocks legitimate traffic - for example an endpoint or a file such as manifest.json or similar - our Support team will continue to investigate and, where appropriate, allow-list it just as quickly as in the past.

The intention behind the change is to keep the baseline WAF configuration consistent across customers and environments, while still reacting fast to unblock legitimate requests. That’s a different matter from, for example, geo-blocking entire regions, black-listing IP ranges, or enabling extra bot-protection rules.

For non-false-positive scenarios that require bespoke filtering (for instance, country-specific or business-specific restrictions), we recommend adopting an in-house perimeter-security layer that fits your own policies and regulatory needs. Many customers are already successful in managing their own traffic with Cloudflare and similar solutions. This separation keeps the shared baseline lean and predictable for everyone. Of course, our InfoSec and Support teams will always keep mitigating urgent business-critical situations that may require a temporary tweak of your WAF.

Looking ahead, we’re also exploring ways to give customers limited self-service for certain temporary blocking actions as a “last-resort” tool. This is still at the discovery stage, so there’s no commitment yet - but it’s on our radar for our 2026 roadmap.

So, in a nutshell, you can expect the same quick, professional support for legitimate false-positive changes as you experienced in the past.

I’m happy to clarify anything in more detail or to discuss future needs at any time.

Best regards,
Ángel
Product Management at Spryker