Web application security
An upload.
An unexpected execution path.
How upload handling, storage permissions, and server configuration can combine into a serious application-security risk.
Client names and sensitive details are withheld. This walkthrough illustrates the testing approach; it is not a reproduced client report.
Assessment focus
At a glance.
At a glance
- Assessment
- Web application file handling
- Access
- Authorized accounts and synthetic test files
- Focus
- Validation, storage, execution, ownership
- Publication
- Illustrative methodology; no client logs or timings
Why it matters
The filename is only one check.
A safe upload feature needs more than an extension filter. Validation, storage location, execution permissions, and access controls all contribute to the boundary.
The work
How this class of assessment works.
Illustrative methodology, not a reconstructed client timeline.
01
Understand the workflow
Map intended file types, upload and download paths, and which users should have access.
02
Review validation
Examine how the server handles client-supplied metadata, content, and names within the agreed testing limits.
03
Check storage boundaries
Determine whether stored files can be executed or accessed outside the intended workflow.
04
Validate remediation
Repeat the agreed checks after a fix, including access-control regression tests for uploaded records.
Findings
What we look for.
01
Validation assumptions
Client-supplied names and content types cannot establish that a file is safe on their own.
02
Execution boundaries
Uploaded content should not become executable application code merely because of where it is stored.
03
Object authorization
Downloading an uploaded record must enforce the requesting user's permission to access it.
04
Layered fixes
Combine validation, non-executable storage, generated names, and server-side access controls according to the application architecture.
Evidence
The boundary, illustrated.
Illustrative example only. No client logs, metrics, or retest results are shown.
BeforeRisky design
Trust the supplied filename. Save inside an executable web path. Return a public, predictable URL.
AfterSafer design
Validate the permitted content. Generate the storage name. Keep storage non-executable. Authorize access through a handler.
This diagram explains a class of issue. It is not a proof of exploitation against a named or unnamed client.
Outcome
What the report should explain.
The reporting objective is to show which conditions create the risk, the evidence supporting the finding, and the specific controls that break the path. Any retest result should be recorded against the agreed scope rather than treated as a guarantee that the application is secure.
Your environment
Define your assessment.
Tell us about your systems and concerns. We will help you define a practical testing scope.