Safeurl Laravel Package

Product Decisions This Supports

• Open-redirect and unsafe-link hardening as a build-vs-buy call. Safeurl wraps URL validation/allowlisting for user-supplied redirect targets and outbound links. This lets the roadmap treat "safe external URL handling" as a small composer dependency rather than a bespoke internal validation module with its own test and review surface.
• Feature decisions touched: any flow that accepts a destination from a user — post-login ?redirect_to=, marketing/campaign redirectors, OAuth/SSO return URLs, webhook and callback URL registration, email-link builders, deep-link handlers, and "trusted partner" outbound links. If a feature ships a user-controlled Location: header or an outbound hop, this package is relevant.
• Roadmap timing input: v1.2.0 adds ^13.0 Laravel support, which is a forward-compatibility signal rather than a feature. It de-risks the Laravel major-upgrade line item: teams planning a Laravel 13 migration do not need to budget removal, fork, or replacement work for this dependency, and the maintainer is tracking framework releases promptly after a major.
• Security-posture narrative: useful as concrete, cheap evidence in security reviews, pentest remediation, and SOC2-style questionnaire answers ("external redirect targets are validated against an allowlist by a maintained library"). Low-cost win relative to writing and maintaining the same logic in-house.
• Not a product differentiator. It is infrastructure hygiene. Do not put it on a customer-facing roadmap, and do not let its presence substitute for a real decision about which destinations are allowed — the allowlist policy is the product decision, the package is only the enforcement mechanism.

When to Consider This Package

Consider it when:

• Any endpoint accepts a caller-supplied URL that will be used for a redirect, callback, or outbound request. This is the core use case and the highest-value moment to adopt.
• You want one reviewed, tested implementation of URL/allowlist validation instead of per-feature ad hoc filter_var() checks — consistency matters more than sophistication here.
• You are on or moving to Laravel 13. v1.2.0 explicitly supports ^13.0, so adoption now avoids a pin-and-patch cycle during the upgrade window.
• You want a mature, narrow dependency from an established maintainer rather than a first-party module — the small surface area means low integration cost and easy exit.

Look elsewhere when:

• You need SSRF protection, not redirect safety. Blocking private/link-local IPs, DNS-rebinding defenses, and egress filtering are a different problem. Validate that this package's guarantees match the threat you are actually mitigating; do not assume the two overlap.
• The allowlist must be dynamic, per-tenant, or policy-driven at scale — you will be building the policy layer on top regardless, and may prefer to own the whole thing.
• You need framework-agnostic URL validation in non-Laravel services (workers, Go/Node edge services, mobile clients). A Laravel package creates a split-brain validation story across the stack.
• Your architecture already routes all outbound/redirect traffic through a gateway or edge rule that enforces this — a second in-app layer is defense in depth at best, duplicated policy at worst.
• Upgrade-cadence risk: the release history here is thin (v1.1.0 → v1.2.0 with a single composer change). A small maintainer footprint means framework-major support depends on one person's availability. Pin the version, and confirm your dependency policy tolerates a low-velocity upstream — fine for a leaf utility, not for anything on the critical auth path without a fallback.

Adoption criteria: it should be a leaf dependency, no service-provider magic required in hot paths, covered by your existing redirect tests, and removable in an afternoon. It meets that bar.

How to Pitch It (Stakeholders)

For executives (one line): A small, actively maintained library that closes the open-redirect class of vulnerability across every feature that accepts a user-supplied link — cheaper and safer than building it ourselves, and its new Laravel 13 support means it will not block our next framework upgrade.

For engineering:

• Adopt as a leaf dependency for redirect-target and callback-URL validation. It replaces hand-rolled filter_var/regex checks with a single reviewed implementation, which is the actual win: consistent behavior and one place to reason about policy.
• v1.2.0 is a compatibility release — ^13.0 Laravel support, no API changes, no deprecations, no breaking changes. Low-risk, non-urgent. Fold it into the next routine dependency bump; no dedicated migration needed.
• Scope it honestly: this addresses redirect/allowlist safety, not SSRF. Do not present it as covering private-IP or DNS-rebinding defenses — that needs separate treatment.
• The allowlist contents remain an engineering/product decision per feature. The package enforces policy; it does not define it. Add a test asserting rejection of an off-allowlist destination wherever it is wired in.
• Risk to note in the ADR: single-maintainer, low release velocity. Pin the version, keep the integration shallow, and treat the escape hatch (a ~50-line in-house validator) as known and cheap.