Greymatter.ioGreymatter.io
Start for Free
Greymatter.ioGreymatter.io Why Greymatter.io?
Pricing Start for Free
Product • Web Application Firewall

Others guess. We prove.

Live the second you deploy. No extra setup needed.

Production Platform 88 svc · 12 ns Filter WAF by namespace, service, rule or tag ▲ 10 degraded● 743 healthy
GuardrailsDLPWAF 1h24h7d
WAF all services◆ Enforcing
REQUESTS WITH A MATCH
133
WOULD HAVE BEEN BLOCKED
0
BLOCKED
41
CRITICAL
3
Where: namespaces over time
checkout133
STATUSTIMESTAMPEVENT
■ BlockedOct 21, 1:33:56 PMSQL injection · 942100 attack
ns checkout / svc checkout-api
▲ Would blockOct 21, 1:33:15 PMScanner detected · 913100 scanner
ns edge / svc edge-gateway
Product view · sample data. Names and identifiers are obscured.
Verified, not claimed
Detect, then enforce.
See what would have been blocked before you turn blocking on.
See what you get →
FIPS 140-3 validated
(CMVP #5191)
Validated by NIST.
See Security Standards →
OWASP CRS 4+
The current Core Rule Set, built in.
Talk to an expert →
What you get, day one

Real protection, out of the box.

Effort is not the problem. Reach is. One unwatched corner is all it takes to expose everything behind it. Greymatter.io checks inbound traffic at your edges and at any service you choose.

Coverage
Edges + services
Checks inbound traffic at your edges and at any service you turn it on for.
Detect, then enforce
Blocking waits on your word.
detect · loggedWOULD BLOCK
enforce · stoppedBLOCKED
Detection shows what would have been blocked. Your team turns on blocking when ready.
Attack matching
A harmful request looks just like a real one, until it gets caught.
942100 · SQL injectionMATCH
941100 · cross-site scriptingCLEAR
930100 · path traversalCLEAR
Each request is scanned against the OWASP Core Rule Set before it touches your app.
Audit logging
No record, no proof. Now you have both.
checkout-api · 942100LOGGED
reviews-web · 941100LOGGED
Each attack match is recorded as structured proof, searchable later.
Policy as code
A new console is a new risk. Policy as code needs neither.
waf: {
  mode: "detect"
  rules: @owasp_crs
}
Fine-tune it with your own rules and exceptions.
How it actually works

What happens to a request, in order.

1
Request arrives

The request could come from outside, or from one of your own services. Either way, it is inspected before it reaches your app, wherever the WAF is turned on.

2
Checked against the rules

The request is compared, line by line, against known attack signatures. The comparison happens right at that same inspection point, before anything moves further.

3
Logged, always

Anything flagged gets written into a record. Your team can search it later, whether blocking is on or off.

4
Blocked, only if you say so

Your team reviews what got caught. Only then do they turn blocking on, system by system.

Production Platform 88 svc · 12 ns Filter WAF by namespace, service, rule or tag ▲ 10 degraded● 743 healthy
Request arrivesSTEP 1 OF 4
RECORDedgeeast-west
Namespace
checkout
Service
checkout-api
Listener
public-edge
Client IP
203.0.●.●
REQUEST
POST /account/login HTTP/1.1
REQUEST HEADERS
content-typeapplication/jsonhostshop.example.comuser-agentMozilla/5.0x-request-id1e2e4e14-●●●●
Try it yourself

Your team decides. Not a vendor default.

Try the toggle below and watch the outcome change.

Interactive · Try it
request inspector
detection mode
POST /account/login user=' OR '1'='1' OR '1'='1
Requestfrom outside
WAFinspection point
Your appreached · logged
FLAGGED SQL injection pattern detected.
WHAT THIS MEANS FOR YOULeft unchecked on a vulnerable app, an attacker could log in as someone else, with no password.

A classic trick: get a login or search field to run a database command instead of searching for text. Here, it is only logged and scored, not blocked, so your team can review it before anything real gets stopped. Switch to Blocking mode to see what happens next.

Somewhere right now, an attacker is testing for your one open gap.

Every unchecked request is an invitation. Close it before someone finds it.

See it in your own environment. No commitment required.
Start for Free Meet Our Security Experts Browse How to Buy →
Go deeper

Want more proof? Here it is.

Use case API Security Control API access and outbound data. Learn more → Product AI Guardrails Keep AI prompts and answers in bounds. Learn more → Product App, API & AI Gateway Route and control API and AI traffic. Learn more →
Swipe for more
Straight answers

Ask before you deploy. Not after you are breached.

No. Greymatter.io does not block traffic right away. It starts by watching and logging every match. Your team turns on blocking later, system by system, whenever you are ready.

The WAF runs inside the proxy as a native filter, not a WebAssembly add-on. There is no separate box to route through.

Yes. Greymatter.io checks traffic between your own systems the same way it checks traffic coming from outside.

Greymatter.io's WAF protects against SQL injection, cross-site scripting, path traversal, command injection, and the other attack categories defined in the OWASP Core Rule Set, matched inline before a request ever reaches your application.

Greymatter.io's WAF checks requests, responses, and WebSocket traffic against the OWASP Core Rule Set.