Prism Browser Laravel Package

Product Decisions This Supports

• Security roadmap priority: v0.1.2 is a security patch, not a feature release. Teams using BrowserPolicy with user-supplied host allow-lists should treat upgrade as a priority, because shorthand IPv4 forms could previously bypass non-public address checks and reach localhost or cloud metadata endpoints.
• Build vs. buy: The package now handles non-obvious IPv4 parsing rules compatible with inet_aton—including integer, octal, hex, and shorthand forms—without DNS. This is exactly the kind of edge-case-heavy security logic most product teams should buy or reuse rather than maintain in-house.
• Feature and use-case fit: Relevant for features that accept URLs or hosts from untrusted input and then make outbound browser/HTTP requests, such as link previews, webhook configuration, scraping, URL validation, integrations, and admin-configured outbound destinations.
• Adoption decision: No breaking changes means upgrading from earlier 0.x versions is likely low-friction, but teams should still validate behavior for digit-only hostnames and any allow-list paths that accept untrusted input.
• Maturity consideration: This is still a 0.x package. The security fix is valuable, but PMs should factor in API stability, maintenance activity, and whether the package covers the full outbound-request security surface needed by the product.

When to Consider This Package

Consider adopting or upgrading when:

• Your Laravel/PHP application lets users, tenants, or admins provide hosts or URLs that are later used for outbound browser/HTTP requests.
• You maintain an allow-list of hosts and need to refuse non-public addresses such as loopback, private network ranges, and cloud metadata endpoints.
• You want to avoid building and maintaining tricky address-parsing and SSRF-bypass protections in-house.
• You need a narrow, application-level policy layer for host/address validation, not a complete network-security program.

Look elsewhere or add complementary controls when:

• The product has no outbound URL-fetching or browser-policy use case.
• You need comprehensive egress filtering, DNS rebinding protection, redirect-chain enforcement, or infrastructure-level SSRF controls beyond an application package.
• The package’s 0.x maturity or maintenance cadence does not meet your risk tolerance for security-critical dependencies.
• You cannot accept host allow-lists from untrusted input without additional validation, monitoring, and defense-in-depth.

How to Pitch It (Stakeholders)

Executive summary: A new security release, v0.1.2, closes an SSRF-style bypass in BrowserPolicy. Attackers could supply shorthand, integer, octal, or hex IPv4 forms—such as 127.1, 0x7f000001, or 2130706433—that browsers resolve to 127.0.0.1, or forms that reach the cloud metadata endpoint. The package now parses these with inet_aton-style rules and refuses them like any other non-public address.

Engineering summary: No breaking changes. Upgrade is recommended if the application allow-lists hosts from untrusted input. Validate existing behavior for digit-only hostnames, which remain names, and add regression tests for shorthand IPv4 and metadata-endpoint cases. This release improves the package’s fitness for security-sensitive URL and host validation, while broader SSRF controls should still be evaluated separately.