Paris, The Thinker, and why your WAF should block XSS by default

With Thales HQ in Paris, it felt right to detour to the Musée Rodin and stand before The Thinker, the bronze giant by Auguste Rodin whose clenched posture and chin-in-hand stance have become a universal symbol of deep judgment. Conceived for The Gates of Hell in 1880 and first cast monumentally in 1904, The Thinker was originally called The Poet and meant to be seen from below, a heroic nod to Michelangelo and to thought as action. Roughly 28 monumental casts exist worldwide, yet the Paris original anchors the myth and reminds us that contemplation only matters when it leads to decisive moves.

If Rodin were chiseling today, what would he make of cybersecurity and the OWASP Top 10? He would likely turn contemplation into muscle. In today’s threat landscape, that means out-of-the-box blocking, not endless time in alert-only mode.

The Challenge

  • The OWASP Top 10 continues to spotlight systemic risks such as Injection, Security Misconfiguration, and other high-frequency failure modes that attackers automate at scale. In the 2021 update, XSS is effectively subsumed under Injection, which reflects its ubiquity and impact.
  • Cross-Site Scripting remains one of the most common web attacks because it is easy to weaponize and hard to eradicate in large codebases. Stored, reflected, and DOM-based XSS can drive account takeover via session or token theft, keylogging, credential harvesting, forced transactions, defacement, and malvertising, often without tripping server-side alarms.

Alert-first sounds cautious, yet it gives attackers a free rehearsal window. Time to exploit often beats time to tune, which leaves you with a pile of alerts, missed needles, and real users exposed while policies inch toward enforcement.

What could go wrong if you do not block by default?

  • A single missed stored XSS in a comment or profile field can persist across sessions, infect administrators and other high-privilege users, and lead to complete application compromise through CSRF chaining and session hijack.
  • Reflected XSS in a marketing parameter can become a turnkey phishing and credential theft campaign minutes after a payload shows up in public repositories or social media.
  • DOM-based XSS triggered by front-end frameworks can bypass server logs, leaving defenders blind until customers complain or until your brand appears in a threat intelligence brief.

The Fix

Imperva’s WAF delivers out-of-the-box protections that combine signature and behavior-based detections with virtual patching and curated policies. When deployed in blocking mode, Imperva’s default policy includes XSS blocking by default, which lets you stop common exploit patterns on day one instead of watching them stream into your SIEM.

Why this matters:

  • High-confidence categories like XSS have mature detection logic, so default blocking cuts dwell time for opportunistic attacks and bot-driven scanning.
  • You reduce mean time to protection to near zero for whole classes of OWASP risks, while you iterate on edge cases and app-specific exceptions at your own pace.
  • Teams reclaim hours otherwise spent triaging alerts and can invest in engineering fixes such as output encoding, CSP, and template hardening that further reduce false positives and long-term risk.

From posture to practice

Rodin designed The Thinker to be seen from below, elevated on a plinth. Your security posture should feel the same: visible, decisive, and defensible. If you haven’t made the jump to OOTB blocking by default by partnering with Imperva; there’s still time. In the interim, we’re all for a safer internet and stopping bad actors, so here’s a practical, block-first playbook:

  1. Turn on blocking for high-confidence classes on day one

    Enable default XSS, SQL injection, and known-bad payload blocking in your WAF’s baseline policy (Imperva supports this when set to blocking mode).

  2. Use staged rollout, not alert-only

    Start in block for low-risk segments or canaries, monitor impact, then expand globally within days, not months.

  3. Tighten signal, not toil

    Apply vendor threat intelligence feeds, automatic signature updates and prefer global exceptions to one-off rule silos.

  4. Pair WAF with app fixes

    Use output encoding, modern templating, strict Content Security Policy, and cookie flags such as HttpOnly, Secure, and SameSite to reduce XSS blast radius.

  5. Observe, learn, iterate

    Review blocked events for false positives weekly, adjust narrowly, and keep the default posture at block for the known-bad.

Proof that block-first works

Imperva customer telemetry shows that organizations are not waiting in alert-only mode. They are enforcing protections out of the box, which is exactly what you would expect from high-efficacy policies with low false positives that require no tuning:

  • 95% of customers have sites with at least one rule in blocking mode.
  • 87% of customers have sites with all rules in blocking mode.
  • 96.6% of all policies in use are default policies with no changes.

These numbers demonstrate that Imperva’s default protections are trusted enough to enable blocking from day one, and customers are not burning cycles hand-tuning rules. Instead of sifting through alerts, they are preventing real attacks.

Security policy as a service, not DIY tuning

This is where Imperva is different. We deliver security policy as a service, with curated and continuously updated rules and threat intelligence designed to minimize false positives, so you do not have to build or tune the policy backbone yourself. Competitors often hand customers a toolbox and expect them to fine-tune rules, which leads to long periods in alert-only mode, slower time to protection, and ongoing operational toil to maintain exceptions and reduce noise. With Imperva, the default policy is the operating standard, not a template you must reshape. The telemetry, especially the 96.6% of policies that are default with no changes, reflects a low false positive rate and a design that minimizes the need for custom tuning.

What to do next

  1. Put high-confidence classes, including XSS and injection, in blocking mode on day one.
  2. Start with canary segments if you need reassurance, then expand quickly as telemetry confirms minimal false positives.
  3. Keep default policies as your backbone and add exceptions narrowly instead of rewriting rules.
  4. Pair enforcement with app-layer fixes to shrink the attack surface and reduce false positives even further.

From a century-old statue to modern web defense, the lesson is consistent. Thinking is the prelude, not the product. In cybersecurity, the action is to block by default, especially for XSS, so your team spends energy shaping a safer system instead of chiseling at an ever-growing pile of alerts. The Thinker made contemplation tangible. Now it is our turn to make our security posture equally solid, elevated, and unmistakably protective.

The post Paris, The Thinker, and why your WAF should block XSS by default appeared first on Blog.