

0 / 2 embers
0 / 3000 xp
click for more info
Complete a lesson to start your streak
click for more info
Still calibrating
click for more info
Not enough gems
Cost: 6 gems
1: Managing Secrets
incomplete
2: Injecting Secrets at Runtime
incomplete
3: Protecting Secrets
incomplete
4: Build Artifacts and Deployment Hygiene
incomplete
5: Limiting Build Context
incomplete
6: Source Code and Config Leaks
incomplete
7: Public File Leaks
incomplete
8: Server-Side Request Forgery
incomplete
9: Defending Against SSRF
incomplete
10: Open Redirects
incomplete
11: Risks of Dependencies
incomplete
12: Auditing Dependencies
incomplete
13: Dependency Maintenance
incomplete
Back
ctrl+,
Next
ctrl+.
This lesson's interactive features are locked, please to keep using them
Imagine a recipe app that correctly limits static serving to web/public/, but leaves web/public/internal-config.json inside that directory. Derp.
You could add special-case handler logic that blocks that one filename. But then the security boundary depends on logic someone might forget to preserve. Remove private data from the public directory entirely. It's simpler, and simpler is easier to keep secure.
An obscure filename or unlinked URL doesn't make a public file private. If server-side code needs the file, store it outside the static root.
Bearly Secure publishes operational details from web/public/internal-config.json. Remove the private file without breaking intended assets.
With Bearly Secure still running, run and submit the CLI tests from the project root.