Treat an upload as untrusted input An uploaded file is not safe because its name ends in .jpg. The browser controls that name, and content can differ from...
Treat an upload as untrusted input
An uploaded file is not safe because its name ends in .jpg. The browser controls that name, and content can differ from the extension. A secure upload workflow validates size and type, stores the file under a generated name, and serves it from an appropriate disk. The application must also decide who can upload, view, replace, and remove the file.
This guide assumes a Laravel application receiving article images or project attachments. Public marketing images and private customer documents need different storage and access rules; do not put both in the public disk by default.
Validate before storing
Laravel's file validation rules can check that a request field is a file, enforce size bounds, and restrict image formats. Apply dimension constraints when the page has a fixed aspect ratio, but allow reasonable source images if an administrator will crop them. SVG is active XML content and needs a separate trust and sanitization decision; do not silently allow it merely because it is an image format.
The validation limit protects the application from excessive uploads, but the web server and PHP upload limits also apply. If the client sees a generic server error for a large file, inspect post_max_size, upload_max_filesize, reverse proxy limits, and the app's validation response.
Use generated storage paths
Store the validated UploadedFile with Laravel's storage API. Let the server generate a random basename or use a trusted identifier plus a generated suffix. Never concatenate the original filename into a filesystem path without careful handling. Save the returned storage path in the database, then render the URL through the disk's URL method or a route that authorizes the download.
Public assets can use the public disk and storage link if the host is configured correctly. Private files should stay on a private disk and be served through an authorization checked response or a short lived signed URL. A guessed URL must not bypass the user's document permissions.
Replace files without losing the old asset
Upload and validate the replacement first. Update the database record to point to the new file, then delete the old file after the update succeeds. If deletion fails, log an orphan cleanup task rather than reverting a valid content update. For high value assets, consider a staged replacement and background cleanup so a storage outage does not leave the article pointing at a missing file.
When several pages use the same image, reference tracking matters. Deleting one article should not remove a shared asset still in use.
Prepare images for delivery
For public article images, create a suitable display size, compress it, and consider WebP or AVIF variants. Preserve a useful aspect ratio and set width and height attributes or CSS aspect ratio to reduce layout shift. Use descriptive ALT text written for the image's information, not a list of target keywords. The featured image for an article should explain or support its subject.
Test security and failure paths
Test an accepted image, a renamed nonimage file, an oversized upload, an unauthorized user, a storage failure, and replacing an existing image. Confirm the old image remains available until the replacement is committed. Confirm private files cannot be opened by another tenant with a copied URL.
Common mistakes
- Trusting the original extension or MIME header alone.
- Storing private documents under a public URL.
- Deleting the old asset before the new upload and database update succeed.
- Returning internal disk paths in an API response.
- Accepting remote image URLs without checking the destination and download behavior.
Conclusion
Secure uploads combine validation, naming, storage permissions, and a recoverable replacement flow. See web and SaaS development for the broader application context.
References