Array Redactor Laravel Package

Product Decisions This Supports

• Safe logging / observability privacy. Decide whether request payloads, job payloads, webhook bodies, and toArray() model dumps can be written to logs, Sentry/Bugsnag, or a support-tooling UI without leaking credentials and PII. This package is the "last mile" scrubber for those arrays.
• Compliance enablement, not compliance itself. Supports GDPR/CCPA data-minimization obligations, PCI-DSS ("never log PANs"), HIPAA-adjacent safeguards, and SOC 2 evidence that sensitive fields are excluded from logs. It is a control implementation detail, not a control.
• Build vs. buy vs. vendor-in. The real decision this informs: do we (a) add a dependency, (b) copy the single-class implementation into our codebase, or (c) push redaction down into the log pipeline (Vector/Fluent Bit/OpenTelemetry processor) or the logging library itself. The package's tiny surface area makes (b) genuinely viable — a rare case where "we could just write this" is the correct answer. New in 1.0.1: callback support in the redaction method raises the ceiling on what "just write this" costs — see the masking note below when sizing the vendored copy.
• Use cases to scope: support/CS dashboards showing raw API payloads to agents; webhook replay and debugging consoles; audit trails; error-tracker context scrubbing; internal admin impersonation views; anonymizing fixtures and seed data.
• Roadmap input for a "secure by default" developer-platform initiative. If redaction is currently opt-in per developer, that's a systemic risk worth a roadmap item (default-on redaction in the shared logging helper) rather than a per-team library choice. Callback support makes a single shared redactor more viable, because team-specific masking needs no longer force teams to fork or bypass the helper.
• A decision to not act. If the log pipeline already scrubs fields centrally, adopting this creates a second, divergent redaction policy — a governance problem, not a security win.

When to Consider This Package

Consider it when:

• You have a PHP/Laravel service that writes structured arrays (request data, queue job payloads, exception context, model arrays) to logs or third-party sinks.
• Your sensitive fields are consistently keyed (password, token, api_key, card_number, ssn) and nested predictably, so key-based matching covers the baseline. Callbacks (1.0.1) let you extend per-key behavior beyond wholesale replacement — partial masking, hashing, or conditional redaction — without leaving the library.
• You have no platform-level scrubbing today, and the alternative is "developers remember to unset fields" — which they won't.
• You accept the maturity profile: dormant upstream (last substantive release 2019-06-08) with a single new 1.0.1 patch, PHP 7-era origins, ~145 stars, 0 dependents, and no visible security-response process. A one-line 1.0.1 release is a data point, not a maintenance commitment — treat upstream as an unreliable supplier and budget for a vendored copy regardless. Verify PHP 8.x / current Laravel compatibility before committing.
• You want a narrow, auditable implementation — a few hundred lines you can read in one sitting beats a heavyweight DLP dependency for a well-understood problem.

Look elsewhere when:

• You need built-in value-based or pattern-based detection — emails, names, or free-text notes containing PII under an innocuous key. Callbacks make this possible to bolt on, but you are writing and owning that logic; if pattern detection is a core requirement, use a purpose-built tool rather than hand-rolling it here.
• You need format-preserving masking or tokenization (last-4 digits, hashing, referential tokens) and don't want to maintain that logic yourself. 1.0.1 callbacks make this achievable inside the library, but nothing is provided out of the box — you own correctness, test coverage, and the audit trail for custom maskers.
• You need to handle streaming payloads, large files, or object graphs beyond arrays.
• Redaction belongs in the infrastructure layer — if you control the logging pipeline, that's a stronger, language-agnostic control point than per-application libraries.
• You require a maintained dependency with a security policy and responsive maintainers.
• You're not on PHP at all (obviously), or you're standardizing on a framework-native solution with equivalent coverage.

How to Pitch It (Stakeholders)

For executives (one paragraph):

We log request and job payloads to debug production issues, and those payloads routinely contain passwords, tokens, and customer PII. Today that protection depends on individual developers remembering to strip fields — which is exactly the kind of control an auditor will probe and an incident will expose. This is a small, MIT-licensed PHP utility that redacts array values before they hit logs, and the latest patch adds callback hooks so teams can mask or hash fields to their own needs instead of working around a one-size-fits-all helper. Roughly a day of integration to materially shrink the blast radius of a log leak and strengthen our GDPR/PCI narrative. My recommendation is unchanged: vendor the implementation into our codebase rather than take it as a dependency. It's a 2019-era library with zero downstream dependents that just shipped its first patch in years — a single 1.0.1 release doesn't give us a support contract, so copying the handful of classes gives us the benefit with none of the supply-chain or upgrade risk. Cost is low; the risk of doing nothing is a recurring, unglamorous audit finding.

For engineering (the pitch and the caveats):

• It's a focused utility: pass an array plus a list of sensitive keys, get the same structure back with those values replaced. It recurses into nested arrays — the part people get wrong when hand-rolling this.
• New: callbacks in the redaction method (1.0.1). Per-key custom logic now lives inside the redactor instead of in every call site. Use it for last-4 masking on card numbers, hashing or tokenizing user IDs, and conditional redaction based on environment. Verify the exact callback signature against the shipped code before building on it — the release note is a single line.
• Wrap it. Put it behind our own Redactor/SafeLog interface so we can swap implementations, enforce a default key list (password, token, secret, authorization, card_number, ssn, *_key), and unit-test the contract rather than the library. Centralizing custom maskers behind that interface keeps callback logic testable and reviewable.
• Default-on, not opt-in. The failure mode isn't "the library is broken," it's "someone logged a raw payload through a different code path." Enforce it in the shared logging helper and add a CI/lint check for direct Log::info($request->all()) calls.
• State the limits loudly in the README: key-based by default, no built-in pattern detection, no built-in partial masking, no protection against PII under an unexpected key. Callbacks give us room to close some of those gaps, but only the ones we explicitly implement and test. Teams must not treat this as a general DLP solution.
• Ownership still required. Assign an internal owner, pin the vendored copy, and log the 1.0.1 callback API as the baseline we fork from. If the project shows continued signs of life, re-evaluate contributing patches back; if it goes quiet again, we've lost nothing.