Skip to content
nsin docs

WAF (Firewall)

A WAF (Web Application Firewall) inspects each request and blocks attacks: SQL injection, cross-site scripting, path traversal, command injection.

nsin’s WAF is managed, on the OWASP Core Rule Set, kept current by nsin. You don’t write signatures — you set where and how strict.

  1. Rules → Add Rule → WAF.
  2. Leave paths as everything, or narrow to a section.
  3. Set strictness and sensitivity (below).
  4. Save in dry run first.
SettingWhat it does
Strictness (paranoia level, 1–4)Checks run. 1: clear attacks only. Higher: subtler attacks, more false positives. Most sites: 1–2.
Sensitivity (threshold)Score builds as checks trip; at this score, blocked. Lower is stricter.
Body inspection limitKB of body checked; uploads capped there. 0 skips it.

A dry-run rule logs what it would block but lets everything through.

  1. Create the rule in dry run.
  2. Leave it a day or two.
  3. Check Monitoring → WAF log.
  4. Real traffic caught: tune it (below). Otherwise, enforce.

The WAF log names which check matched, by rule id — most to least surgical fix:

  1. Exclude that rule id. Everything else keeps working.
  2. Narrow the paths so the WAF skips that endpoint.
  3. Lower the strictness for the whole rule.

Prefer the first over dropping admin-area protection.

  1. WAF rule, whole site, strictness 1.
  2. Stricter WAF rule on /admin/* or your API.
  3. Rate limiting on /login.
  4. Block rules for paths you never serve, like /wp-login.php on a non-WordPress site.

Real visitors are blocked. Find it in the WAF log, note the rule id, exclude it. Several ids for one feature: narrow the path instead.

Does the WAF slow my site down? No — inspection is edge-side, in milliseconds; the body limit keeps it fast.

Do I still need it with a server firewall? Yes — it stops attacks before they cost bandwidth and CPU.

Blocked visitors see nsin’s page. That’s nsin’s 403 page, not yours — error page rules only cover 5xx. See Custom Error Pages.