When changing auth/secret/TLS/validation code, treat existing security semantics as invariants: refactors must not weaken them, and config defaults/warnings must be applied after schema normalization.
Apply this checklist: 1) Preserve security-critical behavior (anti-spoofing / header clearing / response withholding)
Example (anti-spoofing header clearing):
-- Security invariant: headers not present in auth response must not survive
for _, header in ipairs(conf.upstream_headers) do
local header_value = res.headers[header]
-- keep old behavior: nil clears any client-supplied header
core.request.set_header(ctx, header, header_value)
end
2) Ensure fail-open/fail-closed is explicit and testable
3) Encrypt sensitive fields at rest (and verify framework support)
encrypt_fields for every secret stored in plugin metadata/config.4) TLS verification warnings/config must reflect reality
tls.verify (default true) and emit warnings using the established helper, placed after schema defaults are applied so {} is handled as expected.5) Secret-manager integration must load required config in all subsystems
This prevents common production failures: header spoofing regressions, silent fail-open in guards, plaintext secret persistence, missing/incorrect TLS verification warnings, and secret-resolution breakage due to incomplete preload/config coverage.
Enter the URL of a public GitHub repository