--- title: "Firewall & Edge Security for Websites | Serpwise" description: "Stop exploit probes, abusive bots, and traffic floods at the edge. Manage firewall policies, block groups, rate limits, browser security, and evidence from Serpwise." url: "https://serpwise.ai/product/firewall-security/" source: "https://serpwise.ai/product/firewall-security/" --- Firewall & edge security # Stop hostile traffic. Before it reaches your origin. Serpwise inspects requests before your site handles them. Block known exploit paths, abusive bots, unwanted traffic, and floods, then review every decision from one security control plane. [Book a security demo](/demo/) [Read security docs](/docs/shield/) - No origin code or server configuration - Per-domain policies and evidence - Monitor, allowlist, or block Security & traffic Actual product UI ![Serpwise Security and Traffic with protection status, blocked requests, and current signals](/product-screenshots/security-traffic.png) A Serpwise demo workspace showing traffic inspection, blocked decisions, protection coverage, and next-best actions. Figures shown are demo data. Edge-first decisions Blocked requests do not consume origin capacity Managed protection Curated controls without maintaining server rules Security during passthrough Protection continues when HTML changes are disabled The hidden cost of bad traffic ## Your origin should serve customers, not absorb every probe. Scanners, abusive bots, and request floods create more than security risk. They waste origin resources, pollute analytics, and force teams to maintain protection across hosting, application, and CDN layers. 01 ### Origin load Even a harmless 404 costs bandwidth and compute when the request reaches your server. 02 ### Security noise Known exploit paths and scripted probes bury the traffic that deserves investigation. 03 ### Fragmented control Protection becomes slow to change when every policy needs a different vendor, config file, or release. One protection layer ## Control the request, the response, and the evidence. Use focused controls together or enable only what each domain needs. Security runs in the gateway, independent of the client's CMS and application stack. 01 ### Custom firewall policies Define per-domain decisions for traffic conditions such as country, path, bot identity, and request context. Fine-grained traffic control [See rule conditions](/docs/conditions/) 02 ### Managed block groups Enable curated groups for common WordPress, PHP, CMS, dotfile, webshell, configuration, and API probes. Known attack paths stopped at the edge [Explore Block Groups](/docs/block-groups/) 03 ### Exploit Shield Block known exploit paths before origin and temporarily blackhole the source IP after a match. 403 response before origin fetch [Read about Shield](/docs/shield/) 04 ### Rate limiting Use a per-IP sliding window to absorb abusive request volume and return standard 429 backoff headers. Protect origin capacity [See rate limiting](/docs/shield/#rate-limiting) 05 ### Browser security Apply HSTS, framing, MIME, referrer, permissions, cross-origin, and CSP controls without editing server configuration. Standard, strict, and report-only workflows [Review security headers](/docs/security-headers/) 06 ### Decision evidence Review inspected traffic, blocked decisions, bot activity, active protection, current signals, and request-level events. Know what happened and why [Explore analytics](/docs/analytics/) High-leverage protection ## Remove entire classes of scanner noise with one decision. Block Groups package known, high-confidence request patterns into controls you can enable per domain. Matching requests receive a bodyless 404 at the edge before any upstream fetch. Block Groups protect against known request-path probes. They do not replace an application WAF for attacks inside legitimate routes. Managed groups Source control & secrets /.git, /.env, /.aws, /.ssh WordPress probes wp-config, xmlrpc, wp-login PHP & webshell paths phpmyadmin, adminer, shell.php CMS probes Magento, Drupal, Joomla API & docs probes GraphQL, Swagger, actuator Configuration exposure credentials, .sql, Dockerfile Safe controls ### Block or monitor Observe what would match before you actively deny requests. ### Bot filter Apply selected groups to all traffic or known bots only. ### IP allowlist Let trusted office, admin, and partner networks bypass a group. ### Crawler protection Verified Googlebot and Bingbot are exempt from Block Group denial. The request path ## Decide at the edge. Send only allowed traffic forward. Security controls run before normal optimization work and origin processing, so rejected requests stop early while legitimate traffic continues through the Serpwise delivery path. 1. 1 ### Inspect Read the path, request context, and known bot identity. 2. 2 ### Classify Match custom policies, managed groups, Shield, and rate limits. 3. 3 ### Decide Allow, monitor, block, or rate limit according to domain policy. 4. 4 ### Stop or forward Return the edge response or continue the allowed request toward origin. 5. 5 ### Record Write the decision into traffic analytics and security events. Operational control ## Protection you can introduce without gambling on production traffic. Security policy needs a safe rollout path. Serpwise keeps observation, enforcement, exemptions, and fallback close to the decision. ### Monitor before blocking Use monitor mode for Block Groups and report-only mode for CSP while you review real traffic. ### Preserve legitimate access Use IP allowlists, bot filters, and verified crawler exemptions where a policy needs nuance. ### Keep security in passthrough Shield, rate limiting, security headers, and redirects remain active when HTML modifications are disabled. ### Change without an origin release Manage protection per domain without deploying application code or editing web-server configuration. Security product questions ## What technical teams will ask first. 01 Does Serpwise replace our existing WAF? + - Not necessarily. Shield, firewall policies, Block Groups, rate limiting, and browser controls provide a useful protection layer at the Serpwise gateway. Block Groups focus on known request-path probes and should not be presented as a complete application WAF for attacks inside legitimate routes. 02 Can we see what would be blocked before enforcing a policy? + - Yes. Block Groups support monitor mode, and the CSP Builder supports report-only mode. Use those workflows to collect evidence, tune exemptions, and move to enforcement when the results are clean. 03 Will Block Groups interfere with search crawlers? + - Verified Googlebot and Bingbot are exempt from Block Group denial. You can also use bot filters and IP allowlists for policies that need additional control. 04 Does protection still work if we disable Serpwise optimizations? + - Yes. In passthrough mode, HTML modifications stop, while Exploit Shield, the IP blackhole, rate limiting, security headers, and redirects remain active. 05 How quickly do security changes take effect? + - Security settings are applied at the gateway without an origin deployment. Shield and security-header changes apply on the next proxied request, while Block Group configuration propagates across edge nodes within a few seconds. 06 What should we know about current rate-limit state? + - The current Shield implementation keeps rate-limit counters and temporary IP blackholes in memory. They reset on gateway restart and are not shared across gateway instances. We document these limits clearly so teams can decide how Serpwise fits alongside their existing security stack. Bring your traffic pattern ## See which requests Serpwise can stop before origin. Book a security demo with a real domain or traffic concern. We will walk through policy design, managed protection, safe rollout, and the evidence your team receives. [Book a security demo](/demo/) [Read security & trust](/security/)