Clickjacking in Gin with Firestore

Clickjacking is a client-side UI deception attack where an attacker tricks a user into clicking or interacting with a hidden or disguised element. When serving APIs or server-rendered views with Gin and using Firestore as the backend, the risk emerges at the intersection of HTTP response handling, session management, and data exposure. If Gin endpoints render HTML or set permissive frame headers, pages can be embedded in an <iframe> without the user’s knowledge, enabling attackers to overlay invisible controls or hijack authenticated sessions.

In a Gin application, routes that fetch documents from Firestore and render them in templates can inadvertently expose sensitive actions (e.g., confirm email, change settings, or perform writes) if those pages are framed. Because Firestore rules typically enforce authentication and authorization at the document level, the API itself may reject requests lacking valid credentials. However, if the Gin server embeds a Firestore-generated URL or document data into HTML without proper anti-CSRF protections and without setting appropriate frame-busting or X-Frame-Options headers, an authenticated user’s session can be abused inside a malicious page.

Consider a Gin handler that retrieves a Firestore document and renders a settings form without verifying the Referer or Origin headers, and without embedding a CSRF token:

package handlers

import (
	"context"
	"net/http"

	"cloud.google.com/go/firestore"
	"github.com/gin-gonic/gin"
)

type Settings struct {
	Email string `json:"email"`
}

func GetSettings(c *gin.Context) {
	client, err := firestore.NewClient(c, "my-project")
	if err != nil {
		c.AbortWithStatusJSON(http.StatusInternalServerError, gin.H{"error": "failed to create client"})
		return
	}
	defer client.Close()

	userID := c.Param("userID")
	ctx := context.Background()
	doc, err := client.Collection("users").Doc(userID).Get(ctx)
	if err != nil {
		c.AbortWithStatusJSON(http.StatusNotFound, gin.H{"error": "not found"})
		return
	}
	var data Settings
	if err := doc.DataTo(&data); err != nil {
		c.AbortWithStatusJSON(http.StatusInternalServerError, gin.H{"error": "failed to parse"})
		return
	}
	c.HTML(http.StatusOK, "settings.html", gin.H{
		"Email": data.Email,
	})
}

If the rendered page includes an action like POST /update-settings without a CSRF token and is reachable while authenticated, an attacker could craft a page that loads this URL in a hidden iframe or overlays transparent buttons. Because the browser will send cookies (including session identifiers) with the request, the action may execute on behalf of the authenticated user. Firestore security rules may validate the UID in the token, but if the Gin middleware does not enforce same-origin policy and anti-CSRF measures, the API surface remains exploitable via clickjacking.

Additionally, if any Gin endpoint returns sensitive data from Firestore and embeds it in HTML without escaping, an attacker might combine reflected data with social engineering to increase clickjacking lure effectiveness. Therefore, defense must address HTTP headers, frame embedding policies, and state-changing request validation in the Gin layer, while ensuring Firestore rules remain strict.

Remediation focuses on three areas: HTTP response headers to prevent framing, CSRF protection for state-changing requests, and secure handling of Firestore data in Gin templates and handlers.

1. Prevent framing with headers

Configure Gin to set X-Frame-Options and Content-Security-Policy frame-ancestors directives. This instructs browsers to refuse embedding the page in an iframe, mitigating clickjacking regardless of attacker site.

package middleware

import (
	"github.com/gin-gonic/gin"
)

func SecurityHeaders() gin.HandlerFunc {
	return func(c *gin.Context) {
		c.Writer.Header().Set("X-Frame-Options", "DENY")
		c.Writer.Header().Set("Content-Security-Policy", "frame-ancestors 'none'")
		c.Next()
	}
}

Apply this middleware globally or to sensitive routes in your Gin engine:

engine := gin.Default()
engine.Use(middleware.SecurityHeaders())

2. Use anti-CSRF tokens for state-changing operations

For any POST, PUT, PATCH, or DELETE that changes data retrieved from Firestore, require a synchronizer token pattern. Store a cryptographically random token in the session and validate it on submission. Below is a simplified example using encrypted cookies as a session store (in production use a server-side store).

package handlers

import (
	"crypto/rand"
	"encoding/hex"
	"net/http"

	"github.com/gin-gonic/gin"
)

func GenerateCSRFToken() (string, error) {
	b := make([]byte, 32)
	if _, err := rand.Read(b); err != nil {
		return "", err
	}
	return hex.EncodeToString(b), nil
}

func SettingsForm(c *gin.Context) {
	csrfToken, _ := GenerateCSRFToken()
	c.SetCookie("csrf_token", csrfToken, 3600, "/", "", false, true)
	userID := c.Param("userID")
	client, _ := firestore.NewClient(c, "my-project")
	defer client.Close()
	doc, _ := client.Collection("users").Doc(userID).Get(c)
	var data Settings
	doc.DataTo(&data)
	c.HTML(http.StatusOK, "settings.html", gin.H{
		"Email":   data.Email,
		"CSRFToken": csrfToken,
	})
}

func UpdateSettings(c *gin.Context) {
	client, _ := firestore.NewClient(c, "my-project")
	defer client.Close()

	userID := c.Param("userID")
	reqToken := c.PostForm("csrf_token")
	cookie, err := c.Cookie("csrf_token")
	if err != nil || reqToken != cookie {
		c.AbortWithStatusJSON(http.StatusForbidden, gin.H{"error": "invalid csrf token"})
		return
	}

	var payload struct {
		Email string `json:"email"`
	}
	if err := c.BindJSON(&payload); err != nil {
		c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "invalid payload"})
		return
	}
	_, err = client.Collection("users").Doc(userID).Update(c, []firestore.Update{
		{Path: "email", Value: payload.Email},
	})
	if err != nil {
		c.AbortWithStatusJSON(http.StatusInternalServerError, gin.H{"error": "update failed"})
		return
	}
	c.JSON(http.StatusOK, gin.H{"status": "updated"})
}

3. Firestore rule hygiene and data minimization

Ensure Firestore rules do not return more data than necessary to the Gin backend, and that authenticated reads are scoped tightly. Combine this with output encoding in templates to avoid injection via reflected data. For API-driven flows, prefer Gin middleware that validates incoming IDs against Firestore lookups rather than trusting client-supplied identifiers without verification.