Hardening: refuse to serve credential-bearing files (wp-config backups, .env, root SQL dumps) — reject them at POST /extractions validation

[TBarregren]

Summary

Security hardening (defence in depth): the Extractor will currently package and serve any in-scope file the caller selects — including credential-bearing files. On the live smoke test (2026-07-23), the production install root contained wp-config.php.bak-20260717-212309 and wp-config.php.bak-redis-20260718-074109, each holding the full secret family in clear text (DB_PASSWORD, DB_USER/NAME/HOST, AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, all four salts — 24–25 defines each). Both were packaged into the sealed container and landed on the client machine.

This defeats the plugin's own safety posture: GET /environment deliberately masks the secret-define family server-side ("the secrets that never come down"), but the file layer hands the same secrets over anyway, via config backups. Leaving a .bak next to wp-config.php after an edit is extremely common in the wild.

The primary fix lives in the client (kntnt-wp-skills must always-exclude credential patterns from its selection — tracked there), but the server should not rely on every client getting its exclusion set right. The Extractor is the last line of defence for the site's secrets.

Proposed behaviour

Introduce a shared deny-list of credential-bearing path patterns and reject extraction jobs that select a matching file at POST /extractions validation time — fail fast with an explicit error listing the offending paths, so a misconfigured client learns its selection is wrong instead of silently receiving (or silently missing) secrets.

Suggested pattern family (install-root-relative, case-insensitive):

• wp-config.php and any sibling variant: wp-config.php.* (.bak*, .save, .orig, .old, ~, editor swap files), wp-config-*.php — with wp-config-sample.php allowed (no secrets).
• .env, .env.* anywhere in the tree.
• Root-level database dumps: *.sql, *.sql.gz, *.sql.zip directly in the install root.
• Auth/key material: *.pem, *.key, id_rsa* directly in the install root.

Decisions folded into this proposal (adjust if the maintainer disagrees):

• Reject at job creation rather than silently skipping at packaging time — silent skips would desynchronise the client's manifest/baseline accounting and hide the misconfiguration.
• GET /files keeps listing these paths (the manifest stays truthful; clients need to see them to exclude them and to diff baselines). Optionally annotate matching entries (e.g. "restricted": true) so clients can build their exclusion sets from the server's own verdict.
• The deny-list must be a single shared code constant with unit tests — not prose — and documented in the REST contract.

Acceptance criteria

• POST /extractions with a selection containing e.g. wp-config.php.bak-x returns a 4xx naming the offending path(s); no job is created.
• wp-config-sample.php is not blocked.
• The pattern list lives in one constant, covered by tests for each pattern class (positive and negative cases).
• GET /files behaviour documented (unchanged listing, plus the optional restricted annotation if adopted).

References

• Observed in the field: two wp-config.php.bak-* files with full production secrets transferred in clear inside the sealed container (smoke test 2026-07-23).
• Complements the /environment secret-define masking; closes the same hole at the file layer.
• Client-side primary fix: kntnt-wp-skills exclusion-set assembler (tracked in that repo).

Filed from the second live smoke test of the kntnt-wp-skills ⇄ kntnt-extractor cutover, 2026-07-23.

[TBarregren]

Settled decisions (maintainer-approved) — implement per these, not the open questions in the body

The proposal conflicted with ADR-0003 (no server-side categorisation). That conflict is now resolved by a new ADR, ADR-0011 (on main), which is the authoritative decision record for this issue. Summary of what it settles:

1. This is a security boundary, not categorisation — same shape as the existing root-containment rejection. ADR-0003 stands unchanged.
2. Reject at POST /extractions validation time, with a client error naming every offending path; no job is created. No silent skipping at packaging time.
3. Ordering: the deny-list check runs before the existence check (a denied path's existence is not revealed), and — like the rest of the validation ladder — before the capability check.
4. GET /files unchanged: restricted paths stay listed, unfiltered. The optional "restricted": true annotation from the body is rejected — that would be categorisation in the manifest, exactly what ADR-0003 forbids. Callers mirror the published pattern list instead.
5. Pattern family (install-root-relative, case-insensitive), one shared code constant with per-pattern-class positive and negative tests:
   • wp-config.php and sibling variants: wp-config.php.*, wp-config.php~-style droppings, wp-config-*.php — with wp-config-sample.php explicitly allowed.
   • .env and .env.* anywhere in the tree.
   • Directly in the install root only: *.sql, *.sql.gz, *.sql.zip, *.pem, *.key, id_rsa*.
6. Caller-visible contract change → the API version must be incremented, and the deny-list documented in the REST contract as the normative list.

Implementation pointers

• Validation ladder: Extractions_Controller::validate_payload() (classes/Rest/Extractions_Controller.php) — insert the new check after the shape/overlap/key checks, before first_out_of_root_file()/first_missing_table(). Note the ladder runs in the permission callback (can_create()), so the rejection precedes the 403 — tests can prove the status as an unauthorized caller.
• Distinct error code (e.g. kntnt_extractor_restricted_path) with the offending paths in the error data; do not reuse the deliberately non-specific kntnt_extractor_unknown_resource 404.
• Tests: WordPress Playground integration suite — follow the ladder-testing pattern in tests/Integration/extractions-test.php (unauthorized-caller dispatch). Add the new test file/cases to the list in docs/testing-strategy.md.
• Glossary: Restricted path is now a defined term in CONTEXT.md — use it in code, docs, and error identifiers.

The acceptance criteria in the body stand, minus the optional restricted annotation (rejected above).

[TBarregren]

Implemented in 5527b89 (pushed to main). POST /extractions now rejects a selection naming a restricted path with a 422 kntnt_extractor_restricted_path listing every offending path, per the settled ADR-0011 decisions. API version bumped to 3; deny-list published in the README.