CYBERSECURITY
Paste a link for a preview: what does your server actually open?
· MegaDev team
Original AI illustration; it does not depict a real customer or incident.
A link-preview feature may cause a server to fetch content. That is different from an ordinary link a visitor opens in their browser. Before accepting arbitrary addresses, agree the permitted sources and technical limits with the developer.
Establish who makes the request
Ask whether the browser, your server or an external service loads the content. The answer determines which dependencies and data are involved. A screenshot of the completed preview does not show the entire route.
Training example: an imaginary portal adds a summary of a public product page. The team first describes which partner sources are needed and what data may be fetched. No third-party internal services are tested.
Define the risk and permitted scope
OWASP distinguishes SSRF protection for applications connecting only to known, trusted destinations from those that must access arbitrary external addresses. Its guidance covers both application and network controls.
For known destinations, discuss an explicit allowlist. This is a technical requirement, not a suggestion that a business owner should add filters blindly. Different products and infrastructures require different implementations.
Do not rely on the displayed domain alone
The developer should check how the address is interpreted and where the connection is actually made. OWASP warns that allowing a domain name alone is not complete protection: name resolution and the actual connection also matter.
Define behaviour for redirects, retries and refusal. Do not publish lists of internal addresses or bypass methods as part of an ordinary acceptance record.
Test with sources approved in advance
Use test pages under your control: an allowed page, a disallowed destination and an agreed redirect case. Define expected refusals beforehand. Do not target real internal systems without an explicitly authorised technical scope.
Check what the user sees after a refusal and whether the automation remains manageable. Agree suitable time and size limits so a slow source cannot leave the task without a clear ending.
Record the agreed limits
Record an owner, allowed sources, refusal behaviour and cases to retest. A new HTTP library or import type is a reason for technical review. Keep secrets and private addresses out of public documentation.
A successful preview of one page does not prove SSRF protection. This plan helps you accept a specific feature; a full assessment requires a competent review of the application and network environment.
Key takeaways
A URL preview can make a server request, with different risks from an ordinary link.
Allowed destinations and the actual connection route require technical checks.
Use controlled test pages and an agreed scope.
Frequently asked questions
Is an HTTPS link automatically safe?
Checking the scheme alone is not enough. Review the destination and the feature's behaviour.
Can we test with any internal address?
Not as a routine check. Use an authorised test environment and a technical scope defined by the responsible team.
Sources
Sources were checked during preparation on 4 November 2026. Examples and working plans are editorial proposals by MegaDev.
A practical next step
Describe your current process and the difficulty you are facing. Explore the related MegaDev service or discuss your specific task with the team. The scope is agreed for each project.