[{"data":1,"prerenderedAt":143},["ShallowReactive",2],{"publication:en:P154":3},{"meta":4,"copy":16,"relatedArticles":129,"terms":130,"term":131,"resourceParent":137,"glossaryParent":140},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":10,"description":11,"incoming":12,"updated":15},"P154","\u002Fglossary\u002Fssrf","term","what is SSRF","What is SSRF? Server-side requests and destination controls","What is SSRF? Server-side request forgery explained","Understand SSRF, server-side fetching and destination restrictions. Separate input checks, redirects, DNS resolution and actual network access.",[13,14],"\u002Fservices\u002Fsecurity-audit","\u002Fservices\u002Fcrm-integrations","2026-10-30",{"intro":17,"sections":18,"checklist":89,"faq":95,"links":105,"sources":122,"cta":124},"SSRF (server-side request forgery) is a weakness that lets someone influence a server-side application to make an unintended request. The server may be able to reach destinations the visitor cannot access directly. Prevention needs controls on the actual destination and connection, together with appropriate network restrictions; a browser policy or a simple URL-looking check does not settle the server-side risk.",[19,28,64,71,79,84],{"title":20,"paragraphs":21,"sources":24},"Find the business feature that makes the server request",[22,23],"A website may fetch a product image, import a feed or send a callback as part of legitimate work. SSRF concerns how that server-side request is controlled when outside input influences it. OWASP's defensive guidance distinguishes applications that need a known set of destinations from those whose business function accepts broader external destinations. That requirement should be established before choosing a restriction.","Ask the application owner to identify the feature, its input source and the service that performs the request. A visitor typing an address into a browser is a different flow from the website server retrieving that address. Keep those flows separate in the diagram and in the report. The business needs to know which component owns validation and which environment supplies the network access.",[25],{"label":26,"url":27},"OWASP: SSRF prevention, destination checks and network controls","https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FServer_Side_Request_Forgery_Prevention_Cheat_Sheet.html",{"title":29,"paragraphs":30,"table":33},"Map intended destinations before choosing controls",[31,32],"Our server-fetch map turns the technical term into a review that a business and developer can scope. It records the permitted task, destination and owner without including exploit payloads. A feature that only needs a fixed supplier endpoint should not silently become a general-purpose fetch service. Where broader destinations are necessary, document that requirement and its additional review needs explicitly.","Keep the map linked to the current implementation rather than an old integration proposal. Record which redirects, protocols and destination changes the feature legitimately requires. Those decisions affect both security and functionality. A restriction that breaks a required import without a planned alternative is not a complete solution; an unrestricted request justified by convenience is not an adequate acceptance criterion either.",{"caption":34,"headers":35,"rows":39},"Server-side request destination and ownership map",[36,37,38],"Question","Evidence to establish","Acceptance decision",[40,44,48,52,56,60],[41,42,43],"Which feature?","Business purpose and server-side component.","Is the fetch required at all?",[45,46,47],"Which input?","Where destination information originates.","Can the input be replaced with a fixed approved choice?",[49,50,51],"Which destination?","Permitted service, scheme and network scope.","Does the implemented policy match that need?",[53,54,55],"Which connection?","Resolution, redirect and client behavior under review.","Does the actual request stay within the policy?",[57,58,59],"Which network?","Relevant outbound reachability and restrictions.","Is access limited beyond the application check?",[61,62,63],"Which owner?","Developer, infrastructure owner and change record.","Who verifies future integration changes?",{"title":65,"paragraphs":66,"sources":69},"Check the actual connection rather than an address string alone",[67,68],"Destination control needs to account for what the request client ultimately connects to. OWASP discusses redirects, DNS resolution and connection-time enforcement because a validation result can differ from the later network request. Treat an initial address check as one part of the review. The implementation should not validate one destination and then follow an unchecked route to another.","The appropriate mechanism depends on the application and request client. Ask the developer to explain where the policy is enforced and how retries or alternate destinations are handled. Do not paste a generic regular expression or a short list of addresses into production and declare the problem solved. Have an authorized reviewer verify the agreed behavior using controlled destinations rather than a live internal-service probing exercise.",[70],{"label":26,"url":27},{"title":72,"paragraphs":73,"example":76},"Separate application repair from network and browser controls",[74,75],"Application validation and network restrictions address different parts of the same flow. A network control can limit where a process can connect, while the application still needs to distinguish the request it is allowed to make. Keep the two owners coordinated so a change in hosting, integration or container networking does not silently remove the assumed boundary.","Browser CSP, XSS defenses and CSRF protections operate in different contexts. They do not replace the server's destination policy. Likewise, a WAF observation may help identify a request pattern without proving that all internal or outbound paths are controlled. Name the specific control, its enforcement point and the evidence supporting it instead of treating the word firewall as a complete answer.",{"title":77,"text":78},"Illustrative example: importing a product image","A fictional shop imports images from one established supplier. The owner and developer review whether the integration can select an approved supplier endpoint instead of accepting an arbitrary complete address. They document the permitted request and controlled verification before making a change. This is a proposed design discussion, not an exploit test or a claim that a real shop is vulnerable.",{"title":80,"paragraphs":81},"Agree a controlled verification and a useful repair handoff",[82,83],"Verification should cover the intended request and the relevant rejected cases within written scope. Use synthetic input and authorized test destinations, and prevent the test from contacting customer systems or sensitive internal services. Record the tested release, environment and expected result. A single rejected address is not evidence that every parsing or network path has been assessed.","The handoff should identify the feature, affected input, destination policy, application and network changes, functional checks and remaining limitations. If suspicious historical requests exist, keep that incident question separate: repairing a weakness does not establish whether it was previously used. The business may need a scoped evidence review alongside development work, with no unsupported claim about access or extraction.",{"title":85,"paragraphs":86},"Keep the boundary owned when integrations change",[87,88],"A new supplier, redirecting endpoint or hosting migration can change the request path. Include destination-policy ownership in the integration's maintenance record and define who may approve an exception. Revisit the assumptions when the business function changes. A useful baseline explains why access exists and how it is checked, so a later administrator does not broaden it merely to resolve a failed request.","CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide. We bring practical Israeli website and digital-infrastructure knowledge to scoped security and integration work. Describe the feature and affected environment without submitting internal addresses, credentials or customer data through the initial form. No penetration-test coverage, successful exploitation or complete protection is implied before the actual authorized scope is agreed.",[90,91,92,93,94],"Identify which component makes the server-side request.","Define the required destinations and business purpose.","Review redirects, resolution and actual connection enforcement.","Coordinate application and outbound network boundaries.","Record controlled verification, ownership and untested areas.",[96,99,102],{"question":97,"answer":98},"Is SSRF the same as XSS or CSRF?","No, SSRF concerns requests made by a server-side application. XSS concerns unintended browser code execution; CSRF concerns an unwanted browser-authenticated action.",{"question":100,"answer":101},"Does CSP prevent SSRF?","CSP governs browser behavior and does not replace server-side destination controls. Review the application request client and relevant network access.",{"question":103,"answer":104},"Does rejecting one private address prove the issue is fixed?","No: verify the agreed policy and actual request behavior within scope, including relevant redirects and resolution behavior. State what was not tested.",[106,109,112,115,118,120],{"path":107,"label":108},"\u002Fglossary\u002Ffirewall","Understand traffic policy and enforcement points",{"path":110,"label":111},"\u002Fglossary\u002Fcsp","Separate browser content policy from server requests",{"path":113,"label":114},"\u002Fblog\u002Fwebhook-security","Review callback and webhook boundaries",{"path":116,"label":117},"\u002Fblog\u002Fapi-keys-secrets","Limit integration credentials and exposure",{"path":14,"label":119},"Scope a connected application workflow",{"path":13,"label":121},"Agree an authorized technical review",[123],{"label":26,"url":27},{"title":125,"description":126,"button":127,"type":128},"Clarify a server-side integration boundary","Describe the business feature and intended destinations without sending credentials, internal service details or live test payloads.","Discuss the integration review","check",[],[],{"name":132,"aliases":133},"SSRF (server-side request forgery)",[134,135,136],"server-side request forgery","server fetch abuse","server request destination",{"path":138,"label":139},"\u002Fresources","Website security resources and templates",{"path":141,"label":142},"\u002Fglossary","Cybersecurity glossary for small businesses",1794134057974]