Hardening: headers, file editor, request filter
The Hardening area holds three groups of switches: security headers for the frontend, the lock on the built-in file editor, and a filter that rejects requests with typical attack patterns. The switches take effect immediately after saving, without any file having to be touched.
The security headers
- “Send security headers” switches the whole group on and is enabled out of the box.
- “X-Frame-Options” is set to SAMEORIGIN and can be changed to DENY; other values are not provided for.
- “X-Content-Type-Options: nosniff” is on out of the box.
- “Referrer-Policy” sends the value strict-origin-when-cross-origin and is on out of the box.
- “CSP: upgrade-insecure-requests” sets exactly this one directive and is off out of the box; you set up a stricter Content Security Policy separately.
Locking the file editor and filtering requests
- In “Kakapo Security”, switch to “Hardening” (in German: „Härtung“) on the left under “Protection”.
- In the “File editor” card, flip the “Disable file editor” switch; the page reloads afterwards.
- Look at the “DISALLOW_FILE_EDIT constant” row — it shows whether the constant is additionally set.
- In the “Request filter” card, switch on “Bad request filter (WAF-lite)” if you need it; out of the box it is off.
- Then call up your own site and test forms and search parameters.
- “Block known scanner bots” — likewise off out of the box — rejects user agents such as sqlmap, nikto or nmap with status 403.
define('DISALLOW_FILE_EDIT', true);The bad request filter checks the requested address and the values of the query string for patterns such as a null byte, ../../, union … select, <script or php://input. A hit ends with status 403 and an entry in the activity log. Signed-in administrators are exempt from the filter.
The request filter and the bot block only take effect on calls to the frontend. Requests to the admin area, WP-Cron runs and REST requests pass them by.
Was this article helpful?