Backend interview prep

Start

Server-Side Request Forgery (SSRF) Interview Questions and Answers

Learn Server-Side Request Forgery (SSRF) with interview questions, Mermaid diagrams, Spring Boot examples, cloud security considerations, and enterprise best practices.

Server-Side Request Forgery (SSRF) - Interview Questions & Answers

Server-Side Request Forgery (SSRF) is one of the OWASP Top 10 security risks. It occurs when an attacker tricks a server into making unintended requests to internal or external resources.

Unlike attacks such as XSS or CSRF that target the browser, SSRF targets the server itself.

SSRF has become increasingly important in cloud-native applications because attackers often use it to access:

  • Cloud metadata services
  • Internal microservices
  • Private databases
  • Internal admin APIs
  • Kubernetes APIs

Q1. What is Server-Side Request Forgery (SSRF)?

Answer

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker forces the application server to send requests on their behalf.

The attacker cannot directly access internal systems, but the vulnerable server can.

SSRF Overview

flowchart LR

Attacker --> Application

Application --> InternalServer["Internal Server"]

Application --> ExternalWebsite["External Website"]

Example

A web application downloads an image from a URL supplied by the user.

Instead of supplying an image URL, the attacker provides:

http://internal-server/admin

The application unknowingly accesses the internal server.

Q2. Why is SSRF dangerous?

Answer

SSRF allows attackers to use the application server as a trusted proxy.

Potential impacts include:

  • Internal network scanning
  • Accessing private APIs
  • Cloud credential theft
  • Reading sensitive data
  • Privilege escalation
  • Remote code execution (in some environments)

Attack Impact

flowchart TD

SSRF --> InternalApis["Internal APIs"]

SSRF --> MetadataService["Metadata Service"]

SSRF --> PrivateDatabase["Private Database"]

SSRF --> CloudCredentials["Cloud Credentials"]

Q3. How does an SSRF attack work?

Answer

A typical SSRF attack works as follows:

  1. User submits a URL.
  2. Application accepts the URL.
  3. Server sends the request.
  4. Internal service responds.
  5. Sensitive data is exposed to the attacker.

SSRF Flow

sequenceDiagram
participant Attacker
participant Application
participant InternalServer
Attacker->>Application: Submit URL
Application->>InternalServer: HTTP Request
InternalServer-->>Application: Sensitive Data
Application-->>Attacker: Response

Q4. What are common SSRF attack targets?

Answer

Attackers frequently target:

  • Cloud Metadata Services
  • Internal REST APIs
  • Kubernetes API Server
  • Redis
  • Elasticsearch
  • Internal Admin Dashboards
  • Private Databases
  • Docker APIs

Common Targets

mindmap
  root((SSRF Targets))
    Cloud Metadata
    Internal APIs
    Kubernetes
    Redis
    Elasticsearch
    Docker API
    Databases

Q5. Why is SSRF especially dangerous in cloud environments?

Answer

Cloud providers expose metadata services that applications can access to retrieve instance information.

If an attacker reaches the metadata endpoint through SSRF, they may obtain temporary credentials or sensitive configuration data.

Examples:

  • AWS Instance Metadata Service (IMDS)
  • Azure Instance Metadata Service
  • Google Cloud Metadata Server

Cloud SSRF

flowchart TD

Attacker --> Application

Application --> MetadataService["Metadata Service"]

MetadataService["Metadata Service"] --> TemporaryCredentials["Temporary Credentials"]

Best Practice

Use the latest cloud metadata protections (such as IMDSv2 on AWS) and restrict outbound access.

Q6. How can SSRF be prevented?

Answer

Common prevention techniques include:

  • Allow-list trusted destination URLs
  • Block private IP ranges
  • Disable unnecessary outbound requests
  • Validate URLs
  • Restrict supported protocols
  • Use network segmentation
  • Limit outbound firewall rules

Prevention Pipeline

flowchart LR

UserUrl["User URL"] --> Validation

Validation --> AllowList["Allow List"]

AllowList["Allow List"] --> OutboundRequest["Outbound Request"]

Q7. How can Spring Boot applications reduce SSRF risks?

Answer

Spring Boot applications should never make outbound HTTP requests using unvalidated user input.

Recommended practices:

  • Validate URLs
  • Use allow-lists
  • Restrict protocols
  • Configure HTTP clients securely
  • Apply network-level restrictions

Secure Spring Boot Flow

flowchart TD

Client --> SpringBoot["Spring Boot"]

SpringBoot["Spring Boot"] --> UrlValidation["URL Validation"]

UrlValidation["URL Validation"] --> TrustedExternalApi["Trusted External API"]

Interview Tip

Business validation alone is not enough. Network-level controls are also important.

Q8. What are common SSRF implementation mistakes?

Answer

Common mistakes include:

  • Accepting arbitrary URLs
  • Allowing requests to private IP addresses
  • Supporting unnecessary protocols
  • Missing outbound firewall rules
  • Trusting redirects
  • Ignoring DNS rebinding attacks
  • Exposing cloud metadata endpoints

Wrong Design

User URL

↓

Application

↓

Any Server ❌

Correct Design

User URL

↓

Validation

↓

Allow List

↓

Approved Server ✅

Q9. How can SSRF vulnerabilities be detected?

Answer

Detection methods include:

  • OWASP ZAP
  • Burp Suite
  • Penetration Testing
  • Static Code Analysis
  • Dynamic Security Testing
  • Cloud Security Scanners
  • Runtime Monitoring

Detection Pipeline

flowchart TD

Developer --> CodeReview["Code Review"]

CodeReview["Code Review"] --> SecurityScan["Security Scan"]

SecurityScan["Security Scan"] --> PenetrationTest["Penetration Test"]

PenetrationTest["Penetration Test"] --> ProductionMonitoring["Production Monitoring"]

Q10. What are the enterprise best practices for preventing SSRF?

Answer

Follow these best practices:

  • Use allow-lists for outbound destinations.
  • Block private IP ranges.
  • Restrict outbound network access.
  • Validate all URLs.
  • Disable unnecessary URL schemes.
  • Protect cloud metadata services.
  • Apply least-privilege networking.
  • Monitor outbound requests.
  • Keep HTTP client libraries updated.
  • Follow OWASP SSRF Prevention guidance.

Enterprise Architecture

flowchart TD

User --> WAF

WAF --> ApiGateway["API Gateway"]

ApiGateway["API Gateway"] --> SpringBoot["Spring Boot"]

SpringBoot["Spring Boot"] --> OutboundValidation["Outbound Validation"]

OutboundValidation["Outbound Validation"] --> TrustedApis["Trusted APIs"]

Secure Outbound Request Pipeline

flowchart LR

UserInput["User Input"] --> UrlValidationAllowList["URL Validation → Allow List → Firewall Rules → Trusted External Service"]

SSRF Prevention Checklist

mindmap
  root((Prevent SSRF))
    URL Validation
    Allow Lists
    Block Private IPs
    HTTPS
    Outbound Firewall
    Metadata Protection
    Monitoring
    Spring Boot

Senior Interview Tip

SSRF has become increasingly important with the rise of microservices, Kubernetes, and cloud computing.

A production-ready enterprise architecture should combine:

  • Spring Boot
  • Spring Security
  • API Gateway
  • WAF
  • URL Validation
  • Allow-listed outbound destinations
  • Network Segmentation
  • Service Mesh
  • Cloud Metadata Protection
  • Continuous Monitoring
  • Zero Trust Architecture

Remember:

  • Never allow unrestricted outbound requests from your application.
  • Validate every user-supplied URL before making an HTTP request.
  • Protect cloud metadata services from unauthorized access.

Quick Revision

  • SSRF tricks a server into making unintended HTTP requests.
  • It targets the server, not the browser.
  • Common targets include cloud metadata services and internal APIs.
  • Validate all user-supplied URLs.
  • Use allow-lists for outbound destinations.
  • Block private IP address ranges.
  • Restrict outbound network access.
  • Protect cloud metadata endpoints.
  • Monitor outbound HTTP traffic.
  • Combine secure coding, network controls, WAF, and Zero Trust to defend against SSRF.