WAF for a Company Website with No Dedicated Security Team: Managed or Self-Hosted?

Short answer: with no dedicated security team, choose a managed WAF — almost always a cloud vendor's one-click or DNS-based service — over self-hosting. The reason is not that open-source WAFs are weak; it is that a WAF is a living system, not a static appliance. Rules must be updated as bypass techniques evolve, false positives must be triaged continuously, and L7 attacks must be absorbed somewhere with real capacity. A managed service bundles rule updates, capacity, and support into the subscription, which is exactly the work a team of zero security specialists cannot reliably do themselves. Self-hosting becomes the better call only when you have compliance or data-residency constraints that force traffic to stay on your own infrastructure — and even then, you are really signing up for a part-time security job, not a one-time install.

The short answer: managed first, self-hosted only under constraints

Rank your options by how much ongoing attention each one needs, not by sticker price. For a company website (marketing site, portal, or a small set of web apps) with no dedicated security staff, the realistic hierarchy is:

• First choice: managed edge WAF from your cloud provider or a CDN vendor — DNS or load-balancer attach, managed rule sets, built-in rate limiting, and support on call.
• Second choice: the WAF bundled with your existing platform (cloud load balancer, CDN, or hosting provider) — even less to operate, though often less configurable.
• Third choice: self-hosted open-source WAF (ModSecurity/Coraza-style behind Nginx) — full control and no license fee, but you own updates, tuning, and attack response.
• Last resort: building your own filtering logic — you are now a security team, whether you intended to be one or not.

What "no security team" really means for a WAF

A WAF's value decays without maintenance. The attack surface does not stand still: DDoS attacks have evolved to Layer 7 application-layer attacks, and the payloads arrive as valid-looking HTTP that a network firewall happily forwards (source: WAFNinja, verified 2026-08-04). Meanwhile, WAFNinja documents 10 bypass techniques that remain relevant into 2026 (source: WAFNinja, verified 2026-08-04) — encoding tricks, parameter pollution, and chunked-transfer abuse that only work if your rule set is current. Someone has to do that work:

• Rule updates: apply vendor or community ruleset updates on a cadence, not when an incident happens.
• False-positive triage: decide whether each blocked request was an attack or a real user — an over-blocking WAF is a self-inflicted outage.
• Attack response: when a flood or a bypass attempt hits, someone must react within minutes, not days.
• Capacity planning: during a volumetric L7 attack, the bottleneck is bandwidth and compute, not rule quality.

How this guide was put together

This is a comparison of two deployment models — managed versus self-hosted — using a fixed set of criteria: ongoing maintenance required, false-positive handling, attack-response capability, cost structure, compliance fit, and the skill level needed. Sources include WAFNinja's technical articles on network firewalls, WAF bypass techniques, and L7 DDoS protection, plus OWASP documentation. Facts carry sources and a verification date; figures that could not be independently confirmed are marked pending verification. WAFNinja accepts no affiliate payments from any vendor, and this article deliberately makes no "best product" claim.

Comparison table: managed vs. self-hosted WAF

Managed WAF: strengths and honest limitations

Strengths: the vendor maintains rule sets against current bypass techniques; capacity for L7 floods is handled at the edge rather than on your servers; false positives are visible in dashboards with vendor guidance; and deployment is a DNS change or a load-balancer attach.

Limitations you should not ignore:

• Traffic leaves your network — a problem for some regulated industries and privacy policies.
• Pricing is often opaque and usage-based; bills can spike with traffic, and per-request or per-rule pricing adds up. Exact pricing models vary by vendor (pending verification).
• You get less control over the rule engine; some fine-grained rules are impossible through the vendor's UI.
• If your website sits behind the vendor's edge, you depend on their availability — an outage on their side is an outage on yours.

Self-hosted WAF: strengths and honest limitations

Strengths: no license fee, full control over every rule, traffic stays on your infrastructure, and you can tune per route for your exact application.

Limitations you should not ignore:

• You are the security team. Rule updates, bypass testing, and false-positive triage are your ongoing workload.
• Capacity is on you. Under a large L7 flood your bandwidth and compute are the bottleneck — a few thousand hash-collision requests can push a parser to 100% CPU (source: WAFNinja, verified 2026-08-04), and no ruleset stops resource exhaustion by itself.
• The total cost of ownership includes the engineer-hours you will spend; for a small site, that often exceeds the managed subscription.
• If the person who set it up leaves, the WAF often drifts: stale rules, unpatched server, nobody reading logs.

How to choose for your situation

• Public company website, small team, no compliance constraint → managed WAF. Turn on a managed ruleset, monitor the dashboard weekly.
• Regulated industry, data must stay in-country or on-prem → self-hosted, and budget for a part-time security owner — do not pretend it runs itself.
• Static marketing site with no logins and no forms → consider whether you need a WAF at all; platform protections may suffice.
• Website behind an existing CDN → start with the CDN's WAF features before buying a separate product; you may already have enough.
• Tight budget → try the managed option's free tier or the CDN's built-in ruleset first; self-hosting saves license fees but rarely saves money once time is counted.

Step-by-step: deploying a managed WAF without a security team

1. Pick the entry point. If your site is on a cloud provider, attach the WAF to the load balancer or use DNS proxying if the provider supports it.
2. Start in log-only mode. Run one to two weeks observing what would have been blocked. Expect false positives; collect them as evidence, not panic.
3. Enable a managed rule set. Turn on the vendor's OWASP-style default ruleset — do not hand-build rules on day one.
4. Review the weekly dashboard. Blocked requests, top attack sources, and false-positive rate; whitelist only what is clearly legitimate.
5. Switch to blocking gradually. Enable blocking per category (SQLi first, then XSS), not everything at once.
6. Set a calendar reminder to re-check quarterly. Rule sets, pricing, and your own traffic all change; a quarterly 30-minute review keeps the WAF honest.
7. Document who to call. Write down the vendor support path and a rollback procedure (how to disable blocking fast) in your runbook.

Signs you are not ready to self-host

• Nobody on the team has run an OWASP Core Rule Set or tuned a reverse proxy before.
• Logs go unread for weeks at a time.
• The site has no staging environment to test rules before production.
• There is no defined on-call path when an alert fires at 2 a.m.
• The decision was driven purely by "free software" with no accounting for engineer time.

FAQ

Isn't open-source WAF software free, so why pay for managed?

The software is free; the operation is not. Rule updates, false-positive triage, capacity, and incident response are the real cost, and for a team without security staff that cost usually exceeds a managed subscription.

Can my cloud provider's built-in protections replace a WAF?

Partially. Platform-level protections (load balancer rules, CDN rate limits) cover simple abuse. If your site has forms, logins, or APIs, request-level inspection with an updated ruleset still adds real value.

What if the managed WAF blocks a real customer?

It will happen eventually. That is why you start in log-only mode, review dashboards, whitelist legitimate traffic, and keep a fast rollback path. A managed vendor also gives you a support channel for unblocking quickly.

Do I need a WAF at all for a brochure-style company website?

Not necessarily. A static site with no forms, no logins, and no PII may be fine with platform protections. Add a WAF when the site starts accepting input, storing data, or integrating with anything.

How do managed WAF prices actually work?

Pricing is usually based on traffic volume, protected domains, QPS, or a combination — with different traps per vendor (for example, paying per rule or per request). Exact structures vary and are pending verification here; ask for a calculator or a pilot before committing.

Sources and verification

Verified facts used in this article, checked 2026-08-04:

• DDoS attacks have evolved to Layer 7 application-layer attacks — WAFNinja, "Modern DDoS Protection" (evidence A).
• A few thousand hash-collision requests can push a parser to 100% CPU — WAFNinja (evidence A).
• WAFNinja documents 10 WAF bypass techniques relevant through 2026 — WAFNinja (evidence A).
• Network firewalls make decisions at OSI Layers 3 and 4; web traffic uses port 80 (HTTP); SSH uses port 22 — WAFNinja, "Network Firewall vs. WAF" (evidence A).

Vendor pricing structures, SLA details, and specific latency figures are pending verification — confirm against your chosen vendor's current documentation.