App and API protection
Attack attempts read out of your request traces, and how much traffic can be judged.
How an attack attempt is decided #
There is no separate agent for this. A request span is examined as it arrives against a library of attack signatures, each of which recognises one pattern and carries a score for how strongly it indicates an attack.
The scores of every signature that matched are added together, and a request whose total reaches the threshold is an attempt. Scoring rather than flagging means a weak single match stays below the line, while several weak matches together do not.
Why a score rather than a yes
A scanner probing a login form trips a path-traversal signature on its own. Two unrelated weak matches on one request are a different situation, and scoring distinguishes them without needing a rule per combination.
The signature library #
Signatures are grouped by what they detect. Each has its own score, and the strongest signals in the set score highest.
- SQL injection — the largest group, covering union selects, tautologies, blind techniques, schema probing, stacked statements and comment terminators.
- Cross-site scripting — script tags, event handlers, dangerous elements, script URIs and JavaScript sinks.
- Remote code execution — chained commands, shell substitution, reverse shells.
- Log4Shell — the highest-scoring signature in the set, covering plain and obfuscated lookups.
- Server-side request forgery — the cloud metadata service and internal schemes.
- Local file inclusion — path traversal, sensitive files and wrappers.
- Template injection, NoSQL injection, prototype pollution, deserialization, XML external entity, header injection — each with its own patterns.
- Reconnaissance and scanners — introspection probes and the user agents that mark automated tooling.
What the overview reports #
- Attack attempts — requests whose score reached the threshold.
- Answered with a server error — attempts your service actually failed, which is the number that matters most.
- By attack type — which signatures are firing, so you can tell a targeted attempt from opportunistic scanning.
- Top attackers — the client addresses behind them.
- Most attacked endpoints — where to look first.
- Latest attempts — the most recent, for confirming something is ongoing.
Attempts that ended in a server error are separated out because they are the ones you can act on immediately: the request got through and the service failed. An attempt your edge rejected never reached the application and is a different problem, solved at the edge.
Coverage #
This feature reads your request traces, so its coverage is bounded by what your instrumentation captures. The overview reports that coverage directly rather than leaving you to infer it.
- Client address — the share of requests where a client address was resolved. Without it an attempt cannot be attributed to anyone.
- Body — the share of requests carrying a captured body. Without a body, the signatures that look inside one cannot fire.
- Query string — the share of requests carrying a query string, which is where a great many injection attempts live.
- Flows — network flows observed alongside the requests.
Reading a coverage gap
A low body share means the injection signatures are running against a fraction of your traffic, and a low client-address share means the attacker columns are incomplete. Both are worth fixing before you read the attempt counts as an absolute.
Client addresses come from the chain of proxies your traffic passed through, which is set up in Client address attribution.
Limits #
- The overview window reaches back 31 days.
- A request span is judged; internal and remote-procedure-call work is not counted as a web request.
Onward #
Attempts here become Security signals once a rule matches them, and the rules that read them are in Detection rules.