SPEC: further gitea refusals collected in a follow-up issue (closes #6)
Risks now says that gitea requests the Core Rule Set may still refuse at the defaults, found by reading gitea's source, are gathered in #30 and checked against a running gitea in milestone 1, rather than added to the spec one by one. Model: opus-5-5
This commit is contained in:
@@ -1303,7 +1303,10 @@ networks:
|
||||
- Core Rule Set false positives against real apps (a search for code, and any
|
||||
body once `WAF_BODY_LIMIT` is set): a match refuses only that request and bans
|
||||
no one by itself; the request log names the rule, and exclusions by rule id
|
||||
and path fix it.
|
||||
and path fix it. Further gitea requests the Core Rule Set may refuse at the
|
||||
defaults, found by reading gitea's source rather than a running gitea, are
|
||||
collected in https://git.eeqj.de/sneak/smallwebwaf/issues/30 and checked when
|
||||
milestone 1 runs in front of a real gitea.
|
||||
- Attacks carried in request bodies: not refused by default, since on a code
|
||||
forge bodies are full of code the Core Rule Set takes for attacks. Most of
|
||||
what shows in URLs and headers is still refused, the client that sends an
|
||||
|
||||
Reference in New Issue
Block a user