Laravel Attachments Laravel Package

Product Decisions This Supports

• Build vs. buy for attachment/media handling. This package covers polymorphic file and image attachments, ordering, soft deletes, staging, and physical-file cleanup. The v1.4.0 refactor consolidating Image/File into an Attachment model and AttachmentLifecycle signals active maintenance, which strengthens the case for adopting rather than building and owning this logic in-house.
• Go/no-go on user-generated upload features. The security fix closes a stored-XSS class of issue (HTML/SVG/XML/JS uploads retaining executable extensions on the public disk). This de-risks roadmap items such as avatars, comment attachments, support-ticket attachments, and document uploads, and reduces the need for a bespoke security review before launch.
• Product policy on accepted file types. The new allowlist-by-default behaviour forces an explicit product decision about which extensions users may upload. attachments.extra_extensions turns "should we allow SVG/JSON/XML?" into a deliberate, reviewable configuration choice rather than an accidental default.
• Roadmap sequencing. Because public methods, relations, routes, and flash messages are unchanged, this upgrade can be scheduled as routine maintenance rather than a migration project. The behavioural change (non-allowlisted uploads stored as .bin) is the only item needing product/UX verification.
• Risk posture for existing content. Already-stored files are not renamed. This supports a decision to audit existing uploads and decide whether any legacy inline-served files need remediation or re-upload.

When to Consider This Package

Consider adoption when:

• You are building a Laravel application that needs reusable file/image attachments across multiple models (e.g., users, posts, tickets, products).
• You want ordering, soft deletes, staging, and physical-file cleanup handled by convention rather than custom code.
• You can accept an opinionated security default (allowlist of common images, office documents, archives, audio, video) and are prepared to manage extra_extensions deliberately.
• You value a package with an actively maintained internal structure and a stable public API, reducing long-term fork/maintenance risk.

Look elsewhere when:

• You need capabilities beyond attachment lifecycle management: virus/malware scanning, image transformations or CDN delivery, signed URLs, chunked/multipart uploads, or a full digital asset management library.
• You require serving arbitrary file types inline (e.g., SVG previews, XML/JSON downloads rendered in-browser) as a core product requirement; the new default stores these as .bin, and enabling them via extra_extensions carries explicit XSS risk.
• You are not on Laravel/PHP, or you need per-tenant compliance controls that a shared package config cannot express.
• You need guaranteed long-term vendor support or an SLA; this is a community package, so plan for internal ownership of upgrades.

How to Pitch It (Stakeholders)

For executives: This package lets us ship file and image attachment features faster instead of building upload handling, ordering, cleanup, and lifecycle logic ourselves. The new release closes a stored-XSS vulnerability class by default, which lowers security risk for any feature that accepts user uploads. The upgrade is low-effort: the public API is unchanged, and the internal refactor improves maintainability and reduces our long-term fork risk. The one decision we need to make is which additional file types, if any, product wants to allow; that choice now requires an explicit, security-reviewed configuration rather than happening by accident.

For engineering: v1.4.0 is a security release plus an internal consolidation. Uploads now keep their detected extension only if it is on a safe allowlist; everything else becomes .bin. Existing stored files are untouched, so we should audit current uploads and confirm nothing depends on inline SVG/XML/JSON serving. attachments.extra_extensions is available but documented as dangerous for html, svg, xml, js, php, and similar; treat any addition as a security decision. The Image/File → Attachment model refactor and shared AttachmentController / AttachmentLifecycle do not change public methods, relations, routes, or flash messages, so upgrade risk is low. Recommended actions: upgrade, run attachment tests, audit legacy uploads, and document the chosen extension policy.