Security Bundle Laravel Package

Getting Started

This is a Symfony bundle (not Laravel — it targets Symfony 2/3 era kernels), so "day-to-day" means wiring it into AppKernel and config.yml, not a service provider.

Minimal steps:

1. composer require rezzza/security-bundle — pin carefully, the last tagged release is from September 2017 and predates Symfony 4 Flex. Expect to run it on Symfony 2.8/3.x, or to fork/vendor it for anything newer.
2. Register the bundle in app/AppKernel.php:

   new Rezzza\SecurityBundle\RezzzaSecurityBundle(),
   

3. Import a config block (verify exact keys against the bundle's DependencyInjection/Configuration.php, since docs are thin):

   rezzza_security:
       secret: "%secret%"
       signed_request:
           enabled: true
       obfuscate:
           # paths/params the profiler should mask
   

4. Clear cache and confirm the profiler panel/collector changes.

Where to look first: DependencyInjection/Configuration.php (authoritative config schema), then EventListener/ and Security/ for the signed-request flow, then the README. The README is the only real documentation and it's short.

First use case to try: pick the obfuscation half before the signing half. Masking sensitive request data in the profiler is low-risk, instantly visible, and validates that the bundle is actually loaded before you start enforcing signatures on real traffic.

Implementation Patterns

1. Profiler obfuscation (best first win). Configure the paths/parameter names that should be scrubbed (passwords, tokens, auth headers, card numbers) so Web Profiler's Request panel and the Doctrine/HTTP collectors don't leak them. Day-to-day value: you can leave debug mode on in staging without credentials showing up in shared profiler URLs.

2. Signed requests for server-to-server / webhook endpoints. The typical flow is: the calling service signs a request (HMAC over the request with a shared secret), and the bundle's listener validates the signature before your controller runs. Pattern it as an outer guard on a firewall or a dedicated API firewall path:

security:
    firewalls:
        partner_api:
            pattern: ^/api/partner
            stateless: true
            # signed-request listener enforces signature here

Keep the signed-request check in front of authentication, not instead of it — it answers "is this request from someone holding the secret," not "who is this user."

3. Allow-list public endpoints. Anything unauthenticated (health checks, public docs) needs to be excluded, otherwise the listener rejects it. Keep the exclusion list next to the firewall config so route changes stay auditable.

4. Test against the signer, not a mocked listener. When the bundle exposes a signer service, resolve it in functional tests and sign the outgoing request the same way production clients do. This catches canonicalization drift between client and server, which is the #1 source of "works in prod, fails in test" signature bugs.

5. Complement, don't replace, transport security. Signed requests give you integrity and a shared-secret check; they do not encrypt the payload. Keep this behind TLS and use it for integrity/replay resistance, not secrecy.

6. Wrap it in your own thin layer. Given the maintenance state, isolate bundle usage behind one service of yours (e.g. RequestSignatureVerifier) rather than calling bundle services from controllers. If/when you replace the bundle, you swap one class.

Gotchas and Tips

• Maintenance risk is the headline. 16 stars, 0 dependents, ~0.47 "opportunity" score, last release 2017. Treat it as a vendored, inspect-it-yourself dependency. Read the listener code before trusting it on an internet-facing endpoint.
• Symfony version ceiling. The bundle pre-dates Flex/autowiring and Symfony 4+. On modern Symfony you'll likely need composer.json overrides and manual service registration; on Symfony 5+ expect to fork it. Don't promise this to a team on Symfony 6 without a spike.
• Signature mismatch debugging is painful with zero output. When a request is rejected, log the canonical string that was signed on both sides (client and server), not just the resulting hash. Almost every mismatch is a difference in query-string ordering, whitespace, or whether the body is included in the digest.
• Canonicalization is the trap. Decide once, in writing, what the signed payload is: method + path + sorted query + body hash + timestamp. If the client builds it differently (e.g. http_build_query ordering), it fails intermittently depending on parameter order.
• Replay protection needs a timestamp or nonce. A bare HMAC over the request is replayable forever. If the bundle supports a timestamp window, enable it and account for clock skew between services (a couple of minutes of tolerance is normal).
• Obfuscation is profiler-scoped, not a logging or storage control. It silences the Web Profiler; it does not redact Monolog records, access logs, or whatever your app stores. Handle those separately.
• Config-key drift. Because docs are thin and the bundle is old, verify every key against Configuration.php — a silently ignored typo in a YAML block is a very common "why isn't it working" cause. Run config:dump-reference if the bundle supports it.
• Secret handling. The shared secret must come from env/parameters, not be committed. Rotating it means coordinating both sides — plan a dual-secret window so old clients don't break on cutover.
• Profiler leakage via URLs. Obfuscating request parameters won't hide a token that was placed in a path segment. Move secrets to headers/body if you care.
• Extension points worth knowing: the signature listener and any collector/obfuscator decorators are the seams. If you need custom behaviour (e.g. per-client secrets, different algorithms), extend those rather than monkey-patching the bundle.