Platform Gate Laravel Package

Technical Evaluation

What shipped. v0.7.1 is a patch release of funnelchat20/platform-gate, the Laravel package that implements the edge-trust boundary (TrustEdge) — validating the X-Funnelchat-Edge shared secret sent by the Worker in front of each domain. It closes finding Medium S1 from the 13-10 communities audit under the api-abierta initiative: the edge secret was reaching Sentry.

Architecture fit. The package sits where a Laravel package normally sits (service provider + bootstrap component), but this release confirms the trust boundary is process-global, not request-scoped. Because library logs inside TrustEdge are emitted before Laravel's request object is wired, Sentry's PHP SDK builds early events from PHP globals — so the fix is to scrub $_SERVER and $_ENV directly. That is a deliberate, defensible trade-off, but it is a workaround for an ordering problem rather than a clean boundary. Any other consumer reading superglobals before TrustEdge runs (APM agents, custom error handlers, other middleware registered earlier) remains outside the guarantee.

Integration feasibility. High. No config and no code changes: bump 0.7.0 → 0.7.1 or run composer update funnelchat20/platform-gate on ^0.7. Domains upgrade in any order; there is no cross-service contract change because the Worker still sends the same header. Teams on 0.6 follow the 0.6 guide but land on 0.7.1.

Technical risk. The important point for a TPM is that this release alone does not close S1:

• On PHP-FPM the header stays visible to getallheaders() and cannot be deleted from PHP. Each domain must add a Sentry before_send that strips X-Funnelchat-Edge. That is per-domain, manual configuration — the most likely place for this fix to silently regress.
• The secret has already been written to Sentry in the field. The real remediation is rotation of the Worker secret; the notes do not mention it.
• Logging of edge misconfiguration moved from TrustEdge construction to the first request, once per process. That is safer, but it changes when operators see the error and how many copies appear (one per worker process).
• Scrub of $_ENV depends on variables_order; getenv() is not mentioned. Edge cases worth confirming rather than assuming.

Key questions.

1. Does the vendor publish a canonical before_send snippet (Laravel/Sentry SDK version-specific), or do we own writing it per domain?
2. Has the Worker secret been rotated since the leak, and are historical Sentry events containing it purged or expired?
3. Is the scrubber verified under Octane / queue workers, where "once per process" and env reload semantics differ from PHP-FPM?
4. Are other surfaces covered — breadcrumbs, request body/query, LOG_STACK channels beyond sentry (stderr, Papertrail, CloudWatch)?
5. Does TrustEdge scrub $_SERVER under all SAPIs we run, and what is the test matrix?
6. Who signs off that S1 is closed, and on what evidence?

Integration Approach

Stack fit. Standard Composer dependency on a Laravel app; no migrations, no .env keys, no route or middleware registration changes in this release. It is a low-ceremony upgrade that fits an existing CI pipeline as a dependency bump plus regression suite.

Migration path.

• From 0.7.0: change the pin to 0.7.1, or leave ^0.7 and composer update. Deploy.
• From 0.6: follow the "Actualizar desde 0.6" guide but target 0.7.1 instead of 0.7.0 — do not stage through 0.7.0.
• Ordering across domains is unconstrained, which means we can sequence by risk appetite rather than by dependency.

Compatibility. Two caveats drive the plan: (a) PHP-FPM requires the domain-side before_send — the package cannot finish the job; (b) the Sentry SDK's before_send signature is version-dependent, so the scrubber must be written against the SDK version each domain actually runs. If we run Octane, confirm env/secret reload behaviour after rotation.

Sequencing (recommended).

1. Rotate the Worker edge secret — assume exposure until proven otherwise.
2. Roll 0.7.1 to all domains (composer update), any order.
3. Implement the Sentry before_send scrubber per domain, ideally as one shared, version-pinned config package so it cannot drift.
4. Purge or let expire historical Sentry events containing the header; confirm retention window.
5. Canary verification: force an error path and confirm no HTTP_X_FUNNELCHAT_EDGE appears in Sentry, stderr, or any LOG_STACK channel.
6. Close S1 with evidence attached to the audit finding.

Operational Impact

Maintenance. Patch-level upkeep is trivial, but post-release maintenance is not: the before_send scrubber is bespoke per domain and will rot silently as Sentry SDKs are upgraded. Treat it as config-as-code with a test, not a one-off edit.

Support. On-call needs two runbook entries: (1) edge config errors now appear on the first request per process, so a burst of identical lines right after a deploy is expected, not a new incident; (2) a missing or broken before_send produces no error at all — it just leaks. The release notes are Spanish-only; ensure the runbook and the "El borde" doc are readable by whoever is on call.

Scaling. Scrubbing cost is negligible. Log volume for misconfiguration scales linearly with worker count (once per process) — a misconfigured 20-worker pool yields 20 near-identical entries per deploy, which is acceptable but should be filtered or deduplicated in Sentry to avoid alert noise. The before_send runs on every event, so keep it cheap and side-effect free.

Failure modes.

• Silent partial fix: package upgraded, before_send forgotten → secret still in Sentry. Highest-probability failure.
• Forgotten rotation: leaked secret stays valid; scrubbing only stops future leakage.
• Surface gaps: header present in query strings, request bodies, or breadcrumbs not covered by the scrubber.
• Stale env on long-lived workers: after rotation, Octane/queue processes may hold the old secret until reloaded — schedule a restart as part of the rotation step.
• Deploy ordering vs Worker: Worker enabled before the secret is distributed is now logged post-scrub, which is an improvement — make sure that log is actually alerted on.

Ramp-up. Application developers: effectively zero — a version bump and a passing test suite. The real ramp-up sits with the security/Sentry owner: roughly a day per domain to write, review, and verify the before_send scrubber the first time, dropping to minutes once a shared snippet exists. Budget that effort explicitly; it is the difference between a closed audit finding and a reopened one.