Secure Document Pipeline
An end-to-end document workflow with upload validation, secure delivery, metadata mapping, Azure Blob integration and in-application preview rendering.
- Angular
- Node.js
- Express
- Azure Blob Storage
- MongoDB
My contribution
Delivered the upload pipeline end to end — multipart handling and validation, Azure Blob integration, metadata mapping, preview rendering and the controlled delivery path that keeps stored files private.
Key capabilities
Multipart upload handling File validation Azure Blob Storage Secure file access Metadata mapping Document previews
Project context
Business applications accumulate documents — contracts, reports, evidence attached to a record. The moment those files matter, three questions follow: is this file what it claims to be, where is it stored, and who is allowed to see it.
This pipeline answers all three, from the upload control in the browser to the preview rendered back to an authorized user.
Technical challenge
File upload is deceptively simple to get working and easy to get wrong. A file extension is a claim, not a fact; a URL that returns a stored document is a permission boundary, not just a path.
On top of correctness, uploads had to feel immediate. Users attaching documents to a record should not wait on a full round trip before the interface acknowledges them, and previews should render in place rather than forcing a download.
Validating file type and size rather than trusting the client Storing documents outside the application server Keeping stored files unreachable without authorization Rendering previews without a download step
Architecture
Uploads arrive as multipart requests, are validated server-side, and are streamed to Azure Blob Storage rather than persisted on the application server. What the database stores is metadata — the record association, the original filename, content type, size and the storage reference.
Delivery is mediated. The client never receives a permanent public blob URL; it asks the API for a document it is entitled to, and the API resolves and serves it after checking permissions.
Server-side multipart handling with type and size validation Azure Blob Storage as the durable file layer MongoDB metadata mapped to the owning record Mediated delivery instead of public blob URLs
Features
The full path a document travels through the system.
Multipart upload handling with progress feedback Validation of file type, size and expected content Streaming to Azure Blob Storage Metadata mapping to the associated business record In-application preview rendering for supported formats Controlled, authorized document delivery
Security considerations
The pipeline assumes the client is untrusted. Every claim made by the browser — file type, size, which record a document belongs to — is verified again on the server before anything is stored or served.
Content-type and size validated server-side, not from the filename No publicly guessable storage URLs exposed to the client Authorization checked on every document retrieval Filenames sanitized before use in metadata or headers Storage credentials held server-side only
UX considerations
Attaching a document should feel like a small action, not a task. Progress is visible, rejected files explain why they were rejected while the user can still fix it, and previews open in place so reviewing an attachment does not mean leaving the record.
Visible upload progress Specific, actionable validation messages In-place preview without leaving the record Graceful handling of unsupported formats
Lessons learned
Treating the storage layer as private by default and adding a mediated delivery endpoint is far simpler than trying to retrofit access control onto URLs that were once public.
Clear validation messaging removes most support questions. "This file is 24 MB, the limit is 10 MB" resolves itself; "Upload failed" becomes someone else’s afternoon.
Technologies
- Angular
- TypeScript
- Node.js
- Express
- Azure Blob Storage
- MongoDB
- Multipart uploads
Next step
Have a similar system to build?
Tell me what you are working on — the business problem, the constraints, and where the current setup falls short.