Fix XSS in API Responses in FuelPHP

APIs are often overlooked in XSS audits. In FuelPHP, failing to enforce strict Content-Type headers or improperly encoding reflected input allows attackers to execute malicious scripts in the context of the user's browser. If your API reflects input back into a response that a browser might sniff as HTML, you're vulnerable. Secure your endpoints by forcing strict JSON output and sanitizing the context.

The Vulnerable Pattern

public function action_user_info() {
    $user_input = Input::get('name'); 
    // VULNERABLE: Reflects raw input. If accessed via browser, 
    // the default Content-Type might allow XSS via ?name=
    return Response::forge("{\"status\": \"error\", \"message\": \"User $user_input not found\"}");
}

The Secure Implementation

The exploit relies on 'Content-Type' confusion. In the vulnerable example, the developer manually constructs a JSON string but doesn't explicitly set the header, potentially allowing a browser to interpret it as 'text/html'. The secure version uses FuelPHP's 'Format' class to ensure valid JSON structure and 'Security::htmlentities()' to neutralize scripts. Most importantly, it enforces 'application/json' and 'nosniff' headers, which instructs the browser to respect the MIME type and prevents it from executing the payload as HTML.

public function action_user_info() {
    $user_input = Input::get('name');
    $data = [
        'status' => 'error',
        'message' => 'User ' . Security::htmlentities($user_input) . ' not found'
    ];
// SECURE: Use Format class for proper encoding and set strict headers
return Response::forge(Format::forge($data)->to_json(), 404, [
    'Content-Type' => 'application/json; charset=utf-8',
    'X-Content-Type-Options' => 'nosniff',
    'X-Frame-Options' => 'DENY'
]);
}