Managed Rules

Plan tier

The OWASP Core Ruleset this lesson enables is Enterprise-only. The Bot Management rulesets from Lesson 2.4 (Bot Protection, AI Bots) are managed rulesets too, and those come with every plan. If you're not on Enterprise, read along; you've already used the same log-first workflow.

Custom firewall rules cover what you know about. The stock-check rate limit from Lesson 2.3 was your educated guess about where sneaker bots would aim. It's correct for that one specific endpoint. But it's not how all the threats arrive.

SQL injection attempts. Cross-site scripting. Path traversal. Header smuggling. Variants of those that get added every time a new CVE drops. Vercel's managed rulesets implement OWASP top 10 (and a lot more) as a single toggle. You don't write the rules. You don't keep them current. You decide whether they're on, in log mode, or off.

This is the last configuration in the course. We'll flip it on, leave it in log mode for a week, then talk about what to do next.

What are managed rulesets?

Firewall rule collections that Vercel writes and keeps current, covering standard attack patterns like the OWASP Top 10. You choose log or deny per ruleset; Vercel handles what the rules actually match.

Outcome

Saturday has managed firewall rulesets enabled in Log mode. You've reviewed the first round of detections to see what gets flagged on your traffic.

Hands-on exercise 6.5

The same play as Lesson 2.4: log first, deny later.

Requirements:

Open Saturday > Firewall > Rules and find the WAF Managed Rulesets section
Find the OWASP Core Ruleset (the big-bucket "every standard web attack" set). It's configured per rule: enable the rules you want with each action set to Log
If your traffic pattern suggests a specific concern (you're seeing scraper traffic, brute-force sign-in attempts, etc.), enable the relevant rules too
Click Review Changes and Publish. Same as your custom rules, nothing runs until published
Wait at least a few days. Drop-day traffic, weekend traffic, and bot scan windows are all different, a week's data is more representative than a day's
Open Saturday's Firewall overview and review what got flagged. You're looking for:
- Rules that consistently flag real attack traffic (move to Deny)
- Rules that consistently flag legitimate traffic (keep in Log, or write a custom exception)
Move the rules you trust to Deny. Leave anything ambiguous in Log.

Implementation hints:

Log is the low-risk default and genuinely informative. Many teams leave the entire managed ruleset on Log permanently; they don't block anything, but they keep the visibility.
Some managed rules are aggressive enough to flag legitimate traffic (a power user using rare-but-valid headers, a partner integration that uses unusual paths). Logging first protects you from blocking those without realizing.
The full ruleset is large. Don't try to read every rule individually. The category-level toggles are the right granularity for most teams.
Combining managed rules with Bot Protection (from Lesson 2.4) is good defense in depth. Bot Protection labels traffic by source. Managed rules label by payload pattern. Different lenses on the same set of requests.

Try It

Send a request that should trigger a managed rule:

curl "https://YOUR_DOMAIN/?q=' OR 1=1--"

Vercel logs the request as a SQL injection attempt (caught by the OWASP ruleset). In log mode, the request still passes through to your app (which ignores it because the route doesn't care about query parameters). In Deny mode, the request returns a 403 before reaching your function.

Open Saturday's Firewall page and filter to the last hour. You should see the SQLi attempt logged:

2026-05-27T16:08:43Z   /?q=' OR 1=1--
  Match: OWASP Core Ruleset (SQL injection)
  Action: Log
  Source IP: [your test IP]

Try a few more variants:

# XSS attempt
curl "https://YOUR_DOMAIN/?name=<script>alert(1)</script>"
 
# Path traversal
curl "https://YOUR_DOMAIN/../../etc/passwd"

Each should produce its own entry. After a few days of real traffic, you'll see entries you didn't trigger, scanners, drive-bys, the background noise of the internet. That's the visibility managed rules give you.

Done-When

Saturday > Firewall > Rules shows your enabled OWASP rules set to Log, published
A test SQLi or XSS curl request appears on Saturday's Firewall page
You've spent at least 15 minutes reviewing what got flagged
You have a plan for which rules to move to Deny mode after the observation window

Troubleshooting

My test SQLi request isn't getting logged.

Confirm the OWASP rules are actually enabled AND published; a change sitting in Review Changes does nothing. Then wait, the Firewall page can lag by a few seconds. If it still shows nothing after a minute, check which rules you enabled: your test pattern needs a matching rule turned on.

Legitimate traffic is getting flagged in Log mode.

That's the whole reason to start in Log mode. Identify which OWASP rule matched, then write a custom rule that allows that specific path/header combination so it bypasses the managed match. The custom rules from Lesson 2.3 take precedence over the managed set.

Moving rules to Deny mode blocks something it didn't flag in Log.

Rare but possible, the deny path can apply slightly stricter matching than the log path on some patterns. If you see this, roll back to Log for that rule and open a support ticket with Vercel; they can clarify the matching logic.

Solution

The configuration state:

Saturday > Firewall > Rules > WAF Managed Rulesets
  OWASP Core rules:  Log

Saturday > Firewall > Rules > Bot Management   [from Lesson 2.4]
  Bot Protection:    Log
  AI Bots:           Log

After your observation window:

Rules with clean signal-to-noise → move to Deny
Rules with too much noise → keep in Log, or write narrow custom exceptions
Rules you don't understand yet → leave in Log, revisit next quarter

The managed ruleset is the lowest-effort, highest-leverage security layer Vercel offers at the application level. The cost is the time you spend reviewing its detections; the value is everything it catches that you wouldn't have written a custom rule for.

Vercel maintains the certifications that procurement teams and security auditors ask about. You don't have to "configure" any of these, they exist whether you turn them on or not, but knowing where to point an auditor saves you time when the questionnaire arrives.

Certification	What it covers
SOC 2 Type 2	Security, confidentiality, and availability over time. The certification most B2B questionnaires ask about.
ISO 27001:2022	Information security management system standard. Common in EU questionnaires.
PCI DSS	SAQ-D and SAQ-A attestations under PCI DSS v4.0. Required if Saturday handles card data.
HIPAA	Vercel signs Business Associate Agreements with Enterprise customers. Required if Saturday handles protected health data.
GDPR	EU Standard Contractual Clauses for data transfers. Required for processing EU resident data.

The Vercel Trust Center at security.vercel.com is where to find current attestations, request compliance reports, and check the certification scope.

Course outro: the audit, applied

Saturday is now configured. Production runs lean. Previews are gated. Functions cost less than they did. Bots get told to slow down. Old deployments don't accumulate. Audit Logs are streaming somewhere your security team can read them. Sensitive secrets are unreadable. Roles match jobs.

That's the one project. The point of going through all 22 lessons on a single deployment is that you can now do the same audit on the next project in a fraction of the time.

The checklist:

Print this. Walk it through your next project. Most of it is faster than reading the lesson that taught it.

That's the whole course. Go get the rest of your account in shape.

Was this helpful?

On this page

Outcome Hands-on exercise 6.5 Try It Done-When Troubleshooting Solution Compliance: a sidebar Course outro: the audit, applied