Fix XSS in API Responses in Roda

API XSS in Roda usually occurs when raw user input is reflected in the response body without setting the correct Content-Type header or using proper serialization. If an attacker can force the browser to interpret a JSON response as HTML (via content-sniffing), or if a frontend blindly injects the API response into the DOM, you've got an execution vector. Stop building JSON strings manually and start enforcing strict response types.

The Vulnerable Pattern

class App < Roda
  route do |r|
    r.get "profile" do
      # VULNERABLE: Manual string interpolation and missing Content-Type.
      # If 'name' is , it might execute if sniffed as HTML.
      "{\"user\": \"#{r.params['name']}\"}"
    end
  end
end

The Secure Implementation

The vulnerability exists because manual string building fails to escape control characters and defaults to a permissive content type. The fix involves three layers: 1. Use Roda's 'json' plugin which ensures the output is valid JSON and sets 'Content-Type: application/json'. 2. This header prevents modern browsers from performing MIME-sniffing and executing the payload as HTML. 3. Always cast inputs (e.g., .to_s) to ensure you are serializing expected data types. For defense-in-depth, ensure your app sends 'X-Content-Type-Options: nosniff' headers to kill sniffing dead.

class App < Roda
  # SECURE: Use the json plugin to handle serialization and headers
  plugin :json
route do |r|
r.get “profile” do
# SECURE: The plugin automatically sets Content-Type: application/json
# and properly escapes the data structure.
{ user: r.params[‘name’].to_s }
end
end
end