Weave Code
Redactor Laravel Package
kirschbaum-development/redactor
Redactor is a Laravel package for redacting sensitive data before it reaches logs, APIs, or users. Define rules to mask or remove emails, tokens, and other private values from models, arrays, and output with minimal configuration.
Sensitive data redactor for Laravel with entropy detection, key policies, and pipeline support.
Frequently asked questions about Redactor
- How do I install and configure Redactor in a Laravel application?
- Install it with Composer and publish the profile-based configuration file; the package registers a service provider and a Redactor facade automatically. From there you define profiles with detectors and operators, then apply them via the redact:profile middleware, the facade, or Artisan commands such as redactor:scan and redactor:validate. Basic setup is a matter of hours, but a defensible production configuration also needs allowlists, custom rules with samples and counter-samples, and key management.
- Which Laravel and PHP versions does Redactor support?
- The package is Laravel-native, but the advertised version constraints should be confirmed against the composer.json of the exact tagged release you plan to use rather than inferred from documentation. Because the project is at a single stable v1.0.1 with thin public adoption, pin an exact version and commit your lockfile. Validate any registry metadata, including the release date, against Packagist before relying on it.
- How does Redactor detect sensitive data such as emails and tokens?
- Detection is split from the action taken on a match, so detectors report what was found, where, and with what confidence. Built-in detection covers patterns like emails and tokens plus entropy-based detection for high-randomness secrets, and entity recognition is also advertised. Every detection result is then handed to an operator that decides how the value is transformed.
- What is the difference between detectors and operators in Redactor?
- Detectors answer what was found and how confident the match is; operators decide what happens to it. Available operators include redact, mask, partial, hash, surrogate, tokenize, nullify, and preserve. This separation is the key design seam because it lets you tune behaviour by policy, for example keeping the last four digits or keeping logs joinable, without rewriting regular expressions.
- Can Redactor automatically redact log records and HTTP responses?
- Yes, it addresses HTTP responses, log records, streamed output, file scans, and AI prompt or MCP tool results. Coverage is opt-in per surface, so you must map your data flows and enable redaction on each one. Database writes, queue payloads, outbound third-party SDK calls, and storage are not covered unless you instrument them yourself.
- How do I test that sensitive data never reaches output with Redactor?
- The package exposes Redactor::fake() for swapping the implementation in the container and assertNeverEmitted() style assertions you can add to your test suite. The recommended approach is to build an evaluation corpus from your own payloads and wire those assertions into CI as a release gate. Confirm that the fake resolves cleanly in your container setup before depending on it.
- What happens when redaction fails in production?
- The failure posture is designed to be fail-closed: redactSafely(), fail-closed middleware, a sidecar circuit breaker, and a rule that an allowlist entry which cannot be evaluated allows nothing. That direction is correct because a false negative is a data leak, though a false positive can mean corrupted logs or a 500. You must verify the exact per-content-type behaviour of redact:profile against your own payloads and decide whether any route needs a deliberate fail-open exception.
- How do I add custom redaction rules and allowlist specific values?
- Rules live in the publishable profile-based config, and you can extend detection through the Detector contract with your own implementations. The redactor:allow Artisan command manages allowlist entries, and redactor:validate plus redactor:scan help you check profiles and files. Write both samples and counter-samples for every custom rule, because an over-broad pattern will corrupt output just as surely as a missing one leaks data.
- Does Redactor make outbound network calls, and how are hash or surrogate keys managed?
- The package can make outbound calls when verification is enabled or when Presidio or ONNX integrations are used, so a no-egress guarantee must be confirmed in code review rather than inferred from docs. Keys for HMAC-based hash and surrogate operators need a supply and rotation story defined by you, including what happens to log joinability when a key rotates. Both topics deserve explicit security review before production rollout.
- Is Redactor mature enough for production, and what are the alternatives?
- Adoption signal is thin: a single stable release, very few stars, and no known public dependents, so assume no community bug-finding corpus exists. The mitigants are an MIT license, a known Laravel consultancy as vendor, and a codebase small enough to vendor-fork if needed. Many advertised features landed in the first stable release, so verify which ones are actually shipped and tested, and compare against writing your own detector middleware if your surfaces are few.
Weaver
How can I help you explore Laravel packages today?