Clickjacking in Buffalo with Bearer Tokens

Clickjacking is a client-side attack that tricks a user into interacting with a hidden UI element inside an embedded frame. When an application embeds sensitive Buffalo endpoints in an iframe and also relies on Bearer Tokens for authorization, the combination can expose actions to unauthorized execution. Bearer Tokens are typically sent in the Authorization header and are not automatically protected by the browser’s same-origin policy in the same way as cookies with SameSite attributes. If a request is performed from an embedded context (e.g., a malicious site framing your Buffalo app), and the user is already authenticated via a token stored in JavaScript or passed in a header, the request may be sent with the user’s privileges without their knowledge.

Buffalo applications often render server-generated HTML and may include authenticated actions via forms or links that send Authorization headers. If these actions are exposed to an embedded page controlled by an attacker, the attacker can craft a page that overlays invisible elements (e.g., a transparent button or link) over a legitimate UI element. When the user clicks what appears to be a benign element, the hidden request executes with the user’s Bearer Token, performing an action such as changing an email, updating a record, or triggering a state change. Because the request includes a valid token, the server-side authorization logic may treat it as legitimate, especially if the server does not enforce additional context checks like Origin or Referrer validation.

The risk is amplified when Bearer Tokens are stored in accessible JavaScript scopes (e.g., in a SPA or a page that embeds tokens in data attributes) or when preflight requests expose endpoints to CORS without strict rules. An attacker can use a simple iframe and form or script-driven request to initiate state-changing operations. While Buffalo’s server-side templates can mitigate some risks by ensuring that actions are not performed via GET and require CSRF tokens, a token-based approach that relies solely on Bearer tokens without additional context binding may still be vulnerable when endpoints are exposed to embedded frames.

Real-world examples include a dashboard that includes an iframe pointing to an internal reporting endpoint authenticated via Bearer token. If the token is valid and no anti-clickjacking mechanisms are in place, an attacker could load that dashboard in an invisible iframe and simulate clicks on export or delete actions. Similarly, APIs consumed by a Buffalo frontend that expose sensitive operations without checking the Origin header and without requiring user interaction beyond a deliberate action (such as a button with explicit user intent) may be abused through clickjacking techniques.

To assess this risk using middleBrick, you can submit your Buffalo application’s public endpoint for a scan. The tool will run checks including Input Validation and Authentication, and flag whether sensitive actions are exposed in embedded contexts. The scan does not modify your application but highlights findings with remediation guidance, helping you focus on defenses such as frame prevention and token binding.

Remediation for clickjacking when using Bearer Tokens in Buffalo focuses on preventing unauthorized embedding and ensuring that token usage is bound to the intended execution context. Below are concrete code examples demonstrating secure practices.

1. Prevent embedding with X-Frame-Options

Ensure your Buffalo application sets the X-Frame-Options header to deny framing by untrusted origins. In a Buffalo application, you can set this globally in your actions/app.go or per-route using middleware.

import (
    "github.com/gobuffalo/buffalo"
    "github.com/gobuffalo/buffalo/middleware"
)

func app() *buffalo.App {
    app := buffalo.New(buffalo.Options{})
    app.Use(middleware.ParameterLogger)
    // Prevent clickjacking by disallowing framing
    app.Use(middleware.XFrameOptions)
    return app
}

2. Use Content-Security-Policy frame-ancestors

The modern alternative is to use Content-Security-Policy with frame-ancestors. This gives fine-grained control over which origins can embed your pages.

app.Use(middleware.CSP({
    Options: map[string]string{
        "frame-ancestors": "'self'",
    },
}))

3. Bind Bearer Token usage to same-site context

Do not rely solely on Bearer Tokens for state-changing operations without verifying the request’s origin. Combine token validation with checks on the Origin or Referer header when appropriate. Below is an example of a handler that verifies the token and origin before proceeding.

func secureAction(c buffalo.Context) error {
    authHeader := c.Request().Header.Get("Authorization")
    if authHeader == "" {
        return c.Error(401, errors.New("authorization header missing"))
    }
    expectedToken := "your-secure-token"
    if authHeader != "Bearer "+expectedToken {
        return c.Error(403, errors.New("invalid token"))
    }
    origin := c.Request().Header.Get("Origin")
    if origin != "https://your-trusted-domain.com" {
        return c.Error(403, errors.New("invalid origin"))
    }
    // Proceed with safe action
    return c.Render(200, r.String("Action executed securely"))
}

4. Avoid exposing tokens in client-side storage

If your Buffalo frontend is a SPA, avoid storing Bearer Tokens in localStorage or other accessible storage that can be read by embedded scripts. Instead, use short-lived tokens delivered via secure, HttpOnly cookies when possible, or ensure that token injection occurs only in secure, same-site contexts.

// Example of setting a secure cookie in Buffalo (server-side)
cookie := &http.Cookie{
    Name:     "auth_token",
    Value:    generateJWT(),
    HttpOnly: true,
    Secure:   true,
    SameSite: http.SameSiteStrictMode,
}
http.SetCookie(c.Response().Writer, cookie)

5. Require explicit user action for sensitive operations

Ensure that state-changing operations require a deliberate user action beyond a simple GET request. Use forms with CSRF protection and ensure that Bearer Token usage is tied to a session or context that cannot be triggered by an embedded frame.

<form action="/account/update-email" method="POST">
    <input type="email" name="email" required>
    <button type="submit">Update Email</button>
    <input type="hidden" name="_csrf_token" value="{{ .csrfToken }}">
</form>