Missing Tls in Fiber

Missing TLS in Fiber applications creates several attack vectors that directly impact the security of your API endpoints. When TLS is not properly enforced, attackers can exploit multiple vulnerabilities specific to Fiber's architecture.

One of the most common manifestations is credential interception during authentication flows. Fiber applications often use middleware for JWT validation or session management. Without TLS, these tokens are transmitted in plaintext, allowing attackers to capture authentication credentials through network sniffing. This is particularly dangerous in public Wi-Fi environments where man-in-the-middle attacks are trivial to execute.

Another critical issue appears in Fiber's request binding mechanism. Fiber automatically binds request data to struct fields, which can include sensitive information like API keys, passwords, or personal data. When TLS is missing, this data travels unencrypted across the network. An attacker positioned between the client and server can capture this information directly from the request body or headers.

Cross-site request forgery (CSRF) attacks become significantly more effective when TLS is absent. Fiber's CSRF middleware, while helpful, cannot protect against attacks where an attacker can intercept or manipulate requests in transit. Without the integrity guarantees of TLS, attackers can modify requests or inject malicious payloads that Fiber's validation mechanisms cannot detect.

API rate limiting in Fiber also becomes ineffective without TLS. Rate limiting typically relies on IP addresses or user identifiers to track request counts. When TLS is missing, attackers can easily spoof these identifiers or distribute attacks across multiple sources, bypassing rate limiting entirely. This makes denial-of-service attacks trivial to execute against Fiber applications.

Finally, missing TLS impacts Fiber's logging and monitoring capabilities. When sensitive data appears in logs without encryption, it creates a secondary attack surface. Attackers who gain access to log files can extract valuable information without ever needing to compromise the running application.

Detecting missing TLS in Fiber applications requires both automated scanning and manual code review. The middleBrick scanner excels at identifying TLS-related vulnerabilities in Fiber applications by testing the unauthenticated attack surface.

When scanning a Fiber application, middleBrick examines several key areas. First, it checks whether the application listens on port 443 or redirects HTTP traffic to HTTPS. Fiber applications that only bind to port 80 or use the app.Listen method without specifying TLS configuration will trigger a Missing TLS finding.

The scanner also analyzes Fiber's middleware stack for security gaps. If your Fiber application uses middleware like middleware.CORS, middleware.Logger, or custom authentication handlers, middleBrick verifies that these components are configured to enforce secure communication. The scanner specifically looks for patterns where sensitive data might be exposed in headers or request bodies.

For applications using Fiber's OpenAPI/Swagger integration, middleBrick cross-references the specification with runtime behavior. If your spec defines secure endpoints but the actual implementation doesn't enforce TLS, this discrepancy will be flagged. The scanner also checks for API endpoints that should require authentication but are accessible without TLS.

middleBrick's LLM/AI security checks are particularly relevant for Fiber applications using AI features. The scanner tests for system prompt leakage and prompt injection vulnerabilities that become more dangerous when TLS is absent. These checks use 27 regex patterns to detect various LLM prompt formats that could be exposed.

To manually verify TLS configuration in Fiber, examine your main application file. Look for patterns like:

app := fiber.New()
app.Listen(":8080") // Vulnerable - no TLS

Instead, TLS should be configured with certificate files:

app.ListenTLS(":443", "cert.pem", "key.pem")

The middleBrick CLI tool provides quick verification from your terminal:

middlebrick scan https://your-fiber-app.com

This command returns a security score and specific findings about TLS configuration, helping you identify exactly where your Fiber application needs remediation.

Remediating missing TLS in Fiber applications involves several implementation strategies. The most straightforward approach is using Fiber's built-in TLS support through the ListenTLS method.

First, obtain valid SSL/TLS certificates. For development, you can use self-signed certificates or tools like mkcert. For production, use Let's Encrypt or your cloud provider's certificate management. Here's a complete example:

package main

import "github.com/gofiber/fiber/v2"

func main() {
    app := fiber.New()

    // Define routes
    app.Get("/", func(c *fiber.Ctx) error {
        return c.SendString("Hello, TLS!")
    })

    // Start with TLS
    app.ListenTLS(":443", "cert.pem", "key.pem")
}

For applications that need to handle both HTTP and HTTPS traffic, implement automatic redirection:

package main

import (
    "github.com/gofiber/fiber/v2"
    "github.com/gofiber/fiber/v2/middleware/redirect"
)

func main() {
    app := fiber.New()

    // Redirect HTTP to HTTPS
    app.Use(redirect.New(redirect.Config{
        StatusCode: fiber.StatusMovedPermanently,
        HTTPS:      true,
    }))

    // Your routes here
    app.Get("/secure", func(c *fiber.Ctx) error {
        return c.SendString("This is secure!")
    })

    // Start HTTPS server
    app.ListenTLS(":443", "cert.pem", "key.pem")
}

For production deployments behind reverse proxies (like Nginx or cloud load balancers), configure Fiber to trust the proxy headers:

app := fiber.New(fiber.Config{
    Proxy: true, // Trust proxy headers for scheme detection
})

// Middleware to enforce HTTPS
app.Use(func(c *fiber.Ctx) error {
    if c.Protocol() != "https" {
        return c.Redirect("https://"+c.Hostname()+c.Path(), fiber.StatusMovedPermanently)
    }
    return c.Next()
})

Another critical aspect is securing middleware configuration. When using Fiber's middleware for authentication or logging, ensure sensitive data is handled securely:

app.Use(middleware.Logger(middleware.LoggerConfig{
    Format: "${time} ${method} ${path} ${status} ${ip} ${ua}\n",
    // Avoid logging sensitive headers or body content
}))

For applications using environment variables or configuration files with secrets, use Go's crypto/tls package for additional security:

import "crypto/tls"

cert, err := tls.LoadX509KeyPair("cert.pem", "key.pem")
if err != nil {
    panic(err)
}

config := &tls.Config{
    Certificates: []tls.Certificate{cert},
    MinVersion:   tls.VersionTLS12, // Enforce minimum TLS version
}

app.ListenTLS(":443", "", "", config)

Finally, integrate TLS validation into your CI/CD pipeline using the middleBrick GitHub Action. This ensures that any changes to your Fiber application maintain proper TLS configuration:

- name: Run middleBrick Security Scan
  uses: middlebrick/middlebrick-action@v1
  with:
    url: https://staging.your-app.com
    fail-on-severity: high
    token: ${{ secrets.MIDDLEBRICK_TOKEN }}

This configuration will fail your build if TLS is missing or improperly configured, preventing insecure code from reaching production.