Resources · 72
URL imports: prevent unauthorized server requests
Prevent SSRF in downloads, previews and connectors accessing user-supplied addresses.
· 2 min
What this guide helps achieve
- Inventory outbound access
- Restrict destinations
- Limit network access
- Test denials
Quick check
- Which destinations can the component reach?
- Is each redirect checked before connection?
- Are denials tested with mock targets?
Step-by-step method
- 01
Inventory outbound access
List image imports, document retrieval, link previews and connectors. Record protocols, libraries, legitimate destinations and networks reachable from each component. The public interface does not describe server access.
Deliverable: outbound-access map.
- 02
Restrict destinations
For known services, use a strict allowlist. Validate schemes, names, ports and resolved addresses with suitable tools. Check each redirect or disable redirects. A regular expression on URL text is insufficient.
Deliverable: destination policy.
- 03
Limit network access
Add egress restrictions and isolation for the retrieval component. Limit time, size and redirects. Check internal and metadata-service protections without placing secrets in tests.
Deliverable: outbound rules and limits.
- 04
Test denials
In an authorized lab, use mock destinations representing private networks, loopback, redirects and changed resolution. Check rejection before connection and ensure errors disclose no sensitive information. Retain results when connectors change.
Deliverable: negative tests and denial evidence.
Reusable worksheet
Complete with your authorised observations. These fields are a working template, not observed results.
| Field | Information to record |
|---|---|
| Feature | URL input, component and legitimate destinations |
| Policy | Schemes, hosts, ports, resolution and redirects |
| Test | Mock destination, expected and observed denial |
Worked example
Illustrative situation
Fictional example: a preview tool accepts a public test URL redirecting to a mock private service.
Decision and expected evidence
Policy rejects the new destination. The team checks the denial log, transfer limits and absence of returned private content.
Distinguish the mechanisms
| Mechanism | Purpose | Check or limitation |
|---|---|---|
| Known destinations | Restrict to explicitly permitted services | Check resolution and redirects |
| Open external URLs | Support a broader feature | Requires additional isolation and controls |
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Documented outbound access | Features linked to policies | Resolve connectors without owners |
| Verified denials | Forbidden cases blocked before connection | Fix uncontrolled paths |
Common pitfalls
- Validate only the name displayed in the URL
- Allow the component to reach all internal networks
Frequently asked questions
Is HTTPS enough?
No. The protocol does not establish authorization or a stable destination after resolution or redirection.
Can validation exist only in the browser?
No. The requesting service must enforce its policy, complemented by network controls.
Can tests target third-party systems?
Use controlled environments and explicit authorization. The method requires no intrusive third-party testing.
Official references
References consulted: . The method and worksheet propose checks to adapt to your context; they do not constitute certification.
Continue exploring
Related analysis
