SecAuditLogFormat ignored

[odoucet]

It seems overwriting SecAuditLogFormat in coraza-spoa.yaml is ignored.
I tried SecAuditLogFormat OCSF or SecAuditLogFormat JSON and output format is still a long text message.
with log_format=json :

{"level":"error","time":"2025-06-30T17:18:08Z","message":"[client \"82.66.x.x\"] Coraza: Warning. OS File Access Attempt [file \"@owasp_crs/REQUEST-930-APPLICATION-ATTACK-LFI.conf\"] [line \"3146\"] [id \"930120\"] [rev \"\"] [msg \"OS File Access Attempt\"] [data \"Matched Data: etc/passwd found within ARGS_NAMES:/etc/passwd: /etc/passwd\"] [severity \"critical\"] [ver \"OWASP_CRS/4.15.0\"] [maturity \"0\"] [accuracy \"0\"] [tag \"application-multi\"] [tag \"language-multi\"] [tag \"platform-multi\"] [tag \"attack-lfi\"] [tag \"paranoia-level/1\"] [tag \"OWASP_CRS\"] [tag \"OWASP_CRS/ATTACK-LFI\"] [tag \"capec/1000/255/153/126\"] [tag \"PCI/6.5.4\"] [hostname \"redacted\"] [uri \"/stats?/etc/passwd\"] [unique_id \"QQIJHoooKNRZ\"]"}

I tried overriding it before and after coraza.conf-recommended with no luck.

Full coraza-spoa.yaml file :

# The SPOA server bind address
bind: 127.0.0.1:9000

# The log level configuration, one of: debug/info/warn/error/panic/fatal
log_level: info
# The log file path
log_file: /dev/stdout
# The log format, one of: console/json
log_format: json

# Optional default application to use when the app from the request
# does not match any of the declared application names
default_application: default

# To add applications, edit lib/Coraza.php
applications:
  # name is used as key to identify the directives
  - name: default
    # The directives to use for this application
    directives: |
            SecAuditLogFormat OCSF
            Include @coraza.conf-recommended
            SecAuditLogFormat OCSF
            Include @crs-setup.conf.example
            Include @owasp_crs/*.conf
            SecRuleEngine On

    # Optional response check, if set to true, the SPOA will check the response
    # and apply rules accordingly. If set to false, it will only process requests.
    response_check: false

    # The transaction cache lifetime in milliseconds (60000ms = 60s)
    transaction_ttl_ms: 60000

    # The log level configuration, one of: debug/info/warn/error/panic/fatal
    log_level: info
    # The log file path
    log_file: /dev/stdout
    # The log format, one of: console/json
    log_format: json

[hedgieinsocks]

That directive affects only audit log, not hit/error log. I would also like the hit message to be in json, but it looks like coraza left it for the consumers to implement on their own. See corazawaf/coraza#1151

[hedgieinsocks]

@superstes Have you abandoned the idea of the custom callback?

[superstes]

I currently use a fork with the exact callback mentioned in the previous issue for >6 months now without any issues.

I also hope for a native option in the future as this is not optimal..
https://github.com/O-X-L/coraza-spoa/tree/oxl (linux-x64 binary in releases)

[superstes]

@fionera What do you think?
Would formatting the log-output in JSON-format via the callback be an acceptable solution?
It would be user-friendly (and logical) to do so if log_format: json is set.

If you give me some input on the implementation details I could prepare a PR.. 🤔

[hedgieinsocks]

While it would be ideal to add ErrorLogJSON() to https://github.com/corazawaf/coraza/blob/main/internal/corazarules/rule_match.go, I suspect that it might take many months and some persistence to see it come to life.

And given that you already have a working downstream solution, as a consumer and adopter, I'd be happy to see it implemented here first, with the linked issue as a comment. Then we could link our commit to the upstream issue, and when/if it gets implemented, just update our downstream.

Perhaps seeing that coraza's own child project is forced to use workarounds for sane logging, will raise the upstream's issue priority :P

[fionera]

To be hones I don't have an issue with doing this, just don't want to eat the performance penalty of calling json.Marshal for every log line as our GC overhead is already really high (thats an upstream issue but still exists). Maybe just an sprintf with lots of %q as we know the format anyway 🤔

[hedgieinsocks]

Do you mean to mock the payload like that?

mockJSON := fmt.Sprintf(`{"name": "%s", "age": %d}`, "John", 30)
jsonBytes := []byte(mockJSON)

Maybe https://github.com/bytedance/sonic can make encoding overhead negligible enough for us to not care?

[superstes]

Can we escape characters relevant to JSON with a simple fmt.Sprintf? 🤔

BTW - found a benchmark: https://gist.github.com/feckmore/4728f8dc2eda4bb7fa3f33c976ca9e22

If we have to handle escapes ourself I don't think it will outperform the marshal'ing - but we can benchmark some possible solutions.

[fionera]

I just rigged something up. Using a json.Encoder is fine 😄 I really had a bad memory of json being slow. Its actually really fast 😆

goos: linux
goarch: amd64
cpu: AMD Ryzen 9 9950X3D 16-Core Processor          
BenchmarkJSONMarshal-32          9625048               126.1 ns/op           880 B/op          2 allocs/op
BenchmarkJSONEncode-32          24271035                48.14 ns/op          240 B/op          1 allocs/op
BenchmarkSprintf-32              5201413               229.4 ns/op          1176 B/op         23 allocs/op
PASS

[xkpx64]

It will be lovely to be pure json so i can move the logs easy to something like OpenObserve.
SecAuditLogFormat JSON

log_format: console

12:17AM ERR [client "192.168.1.50"] Coraza: Warning. Request content type is not allowed by policy [file "/etc/haproxy-coraza/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "2810"] [id "920420"] [rev ""] [msg "Request content type is not allowed by policy"] [data "|application/dns-message|"] [severity "critical"] [ver "OWASP_CRS/4.18.0-dev"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/PROTOCOL-ENFORCEMENT"] [tag "capec/1000/255/153"] [hostname "192.168.40.3"] [uri "/dns-query"] [unique_id "KZUBYDXDUHIFJGIL"]

log_format: json

{"level":"info","time":"2025-08-02T00:20:40+03:00","message":"Starting coraza-spoa"} {"level":"error","time":"2025-08-02T00:20:54+03:00","message":"[client \"192.168.1.50\"] Coraza: Warning. Request content type is not allowed by policy [file \"/etc/haproxy-coraza/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf\"] [line \"2810\"] [id \"920420\"] [rev \"\"] [msg \"Request content type is not allowed by policy\"] [data \"|application/dns-message|\"] [severity \"critical\"] [ver \"OWASP_CRS/4.18.0-dev\"] [maturity \"0\"] [accuracy \"0\"] [tag \"application-multi\"] [tag \"language-multi\"] [tag \"platform-multi\"] [tag \"attack-protocol\"] [tag \"paranoia-level/1\"] [tag \"OWASP_CRS\"] [tag \"OWASP_CRS/PROTOCOL-ENFORCEMENT\"] [tag \"capec/1000/255/153\"] [hostname \"192.168.40.3\"] [uri \"/dns-query\"] [unique_id \"FKUKOIHLFXDWLOSJ\"]"}

[superstes]

I'll take some time the next days to supply a PR with a draft 👍

[fionera]

Just openend #264 . Thank you @superstes