Referer Cookie Bundle Laravel Package

Technical Evaluation

What it is: A Symfony bundle (*Bundle naming, DI extension + service wiring) that reads the inbound Referer header and persists it to a first-party cookie — a lightweight referrer/attribution capture mechanism. It is not a Laravel package, which is the first and most consequential finding.

Architecture fit: Poor for a Laravel stack. Bundles rely on Symfony's Bundle class, DependencyInjection\Extension, service tagging, and the HTTP kernel event system. Laravel boots service providers, not bundles. Adopting this would mean either (a) standing up a Symfony kernel alongside Laravel to host it — unjustifiable for a cookie write, or (b) rewriting it as a Laravel middleware + config file, at which point you are not adopting the package at all. If the organization is genuinely on Symfony, the architecture fit is fine but the adoption case is still weak (see risk below).

Integration feasibility: High only in the "copy the logic" sense. The functional surface is small and well-understood: inspect Referer, exclude same-host referrers, optionally honour an allowlist/blocklist, write a cookie with configured name, TTL, domain, path, Secure/SameSite. A competent PHP developer can reproduce this in Laravel in roughly 1–2 engineering days including config, tests, and consent gating. That is cheaper than the diligence required to trust an unmaintained third-party here.

Technical risk (high):

• Abandonware. Last release 2021-11-26; zero stars, zero dependents, zero forks of note. No observable maintainer commitment, no issue triage, no security disclosure process. Medelse is a healthtech company, not a package maintainer — this reads as an extracted internal utility published once.
• Compatibility drift. No verified support for Symfony 6/7 or PHP 8.2+. Bundle directory structures, services.yaml conventions, and deprecations have moved materially since 2021. Likely to install but break at container compile time or on deprecated event names.
• Supply chain. MIT license is permissive and low-friction, but a near-zero-adoption package gives the community no coverage — nobody else is watching for a malicious release or a compromised maintainer account. A pinned commit hash mitigates, but does not eliminate, this.
• Privacy/compliance. A referer cookie stores URLs that may contain personal data or identifiers. ePrivacy/GDPR posture matters: writing this pre-consent is defensible only under a strict-necessary or legitimate-interest analysis, and the bundle almost certainly has no consent hook. Legal review is a gating step, not a follow-up.
• Data quality, not just security. Modern browsers default to Referrer-Policy: strict-origin-when-cross-origin, so you will generally receive origin only — no path, no query string. Any product requirement expecting full landing-page attribution will be silently unmet. Cross-site cookie restrictions and ITP/ETP also cap first-party cookie lifetimes in some contexts.

Key questions for the requester:

1. Is the target stack Laravel or Symfony? The answer changes the recommendation from "port it" to "port it or write it fresh."
2. What is the actual product requirement — last-touch referrer origin, UTM capture, or full landing-page URL? Only the third is at risk, and the third is also the riskiest legally.
3. Who owns this code after we ship it? If the answer is "nobody," do not ship it.
4. Has Legal/Privacy signed off on pre-consent referrer capture in our jurisdictions?
5. Is there an existing analytics or attribution vendor that already solves this (Segment, GA4, a CDP)? Purchasing overlap is a reason to close the ticket.

Recommendation: Treat as a reference implementation, not a dependency. Score 0 is the correct read. Reproduce the behaviour natively, with attribution to the MIT-licensed original if code is copied.

Integration Approach

Stack fit: If Laravel — no direct fit; implement as a global or web-group middleware with a config/referrer-cookie.php and an entry in the service container. If Symfony — technically installable via Composer, but pin to a commit and fork into a private VCS (GitHub/Packagist mirror) before use, since upstream is dormant.

Migration path: There is nothing to migrate from — no dependents, no installs. The practical path is greenfield:

1. Spike (0.5 day): read the bundle source, document exact behaviour — header parsing, exclusion rules, cookie attributes, defaults, edge cases (empty referer, malformed URL, same-origin, subdomain handling).
2. Reimplement (1–2 days): native middleware, config file, unit + feature tests covering: no referer, same-host referer, external referer, malformed referer, cookie already present (don't overwrite), and Secure/SameSite correctness.
3. Consent gate (0.5 day): wire behind whatever consent/CMP mechanism exists, or default to disabled until Legal approves.
4. Ship behind a feature flag; validate against real traffic for one to two weeks.

Compatibility considerations:

• Set SameSite=Lax by default; None requires Secure and should not be used for a first-party attribution cookie.
• Do not overwrite an existing referrer cookie — first-touch vs. last-touch is a product decision that must be explicit, and the bundle's default is unlikely to match your requirement.
• Cap cookie value length (URLs can be long) and truncate/sanitise to avoid header bloat and injection.
• Explicitly exclude same-site/subdomain referrers, otherwise internal navigation generates false attribution.

Sequencing: Legal/privacy sign-off → behaviour spike → reimplementation → contract tests → feature flag → canary → full rollout. Do not sequence the privacy review after launch; retrofitting consent onto an already-set cookie is a cleanup exercise with legal exposure.

Effort estimate: 3–4 engineering days total including tests and review. Far below the cost of vendor diligence, fork maintenance, and future Symfony-upgrade compatibility work.

Operational Impact

Maintenance: Effectively zero upstream maintenance. Because you will own the code either way, the only question is whether you own a private fork of someone else's bundle or 150 lines of your own middleware. The latter is cheaper to reason about, upgrade, and delete.

Support: None. No SLA, no maintainer responsiveness, no security advisory channel. Any incident — a bad cookie domain breaking attribution, a Set-Cookie conflict with a session cookie — is yours to diagnose with no upstream backstop.

Scaling: Negligible performance cost — one header read and one Set-Cookie per request. The real scaling concern is caching: if responses are served from a CDN, Varnish, or full-page cache, the Set-Cookie header may be stripped or the cached response served without it, and attribution silently disappears for the majority of traffic. This must be designed for explicitly (bypass cache on the referrer path, or set the cookie client-side after a cache-safe API call). Cookie size also matters at scale — keep values short.

Failure modes to monitor:

• Silent null attribution — referrer suppressed by Referrer-Policy, privacy extensions, or app-to-web transitions. Looks like "no traffic from that channel," not like an error.
• Cache interaction — cookie never set on cached routes (most likely failure in practice).
• Misconfigured cookie domain — cookie scoped to www. only, invisible on app. or apex; attribution breaks for a subset of the funnel.
• Cookie collision — name clash with an existing attribution cookie from a vendor tag.
• Bot inflation — scrapers and preview fetchers writing referrer cookies, polluting downstream analytics.
• Compliance incident — pre-consent writes discovered in a DSAR or audit.

Ramp-up: Low. Any PHP developer can read and modify this in an hour. Documentation is minimal-to-absent, so budget time for the behaviour spike to establish ground truth rather than relying on the README.

Bottom line for the TPM: The cost of adopting this package exceeds the cost of replacing it. Approve the requirement if the attribution gap is real and unowned elsewhere; reject the dependency; fund 3–4 days of native implementation with privacy review as a hard gate.