38 posts tagged with "fiber"

A pull request adds GET /api/admin/export, a CSV download of every customer record. The handler is fine, the test for the CSV format is fine, and the reviewer approves it. Two weeks later somebody notices that the route was registered on the api group instead of the admin group, so the only thing it checked was a valid login. Every customer with an account could download every other customer. Nobody wrote a wrong access rule. The route simply never had one, and nothing in the app noticed.

This is the most ordinary way to end up in A01 of the OWASP Top 10 2025, broken access control, whose first piece of advice is to deny by default. In a Fiber app, "default" usually means "whatever middleware the route happens to inherit from its group". That works until the day a route lands in the wrong place. Fiber v3.6.0 added c.Endpoint(), which lets global middleware see the route that will handle a request before any handler runs. This post uses it to build a single policy table keyed by route name, a middleware that rejects every route the table does not mention, and a startup check that refuses to boot when the table and the routes disagree. Everything was built and tested against Fiber v3.6.1. c.Endpoint(), c.Bearer() and c.SetLocal() need v3.6.0 or later, which requires Go 1.26.

Somebody on your team writes a small helper for the editor. It is a Fiber app on 127.0.0.1:7777 that lists and reads files from the current project, so an editor plugin or a coding agent can ask it for context. It has no authentication, because it only listens on loopback and "nothing outside this machine can reach it". That sentence is half true. Nothing outside the machine can open a connection to it. But the browser on the same machine can, and the browser runs code from every website its user visits.

Over the past months, several Model Context Protocol servers received advisories for exactly this setup, among them genieacs-mcp, whose Streamable HTTP transport listened on 127.0.0.1:8080 without checking Host or Origin. The attack behind them is called DNS rebinding, and it is older than most of the tools it now hits. This post shows how it works, why the usual browser defenses do not notice it, and how the hostauthorization middleware that shipped in Fiber v3.3.0 closes the hole, for local tools and for public servers. Everything was built and tested against Fiber v3.6.1, which needs Go 1.26. The example also uses c.Origin(), which arrived in v3.6.0.

Most CSRF bugs I have seen in Fiber apps were not attacks. They were users who left a form open over lunch, came back, clicked Save and got a 403 because the token in the page had expired. Or an HTMX page where one fragment was rendered without the hx-headers attribute that carries the token. Or a SPA that read the token cookie on startup and kept sending a stale value after the session rotated. The token itself was never the hard part. The plumbing was: every template, every fetch wrapper and every cached page has to carry a value from the server back to the server, and a single gap turns into a support ticket.

Browsers can tell a server where a request comes from. Every major browser engine now sends the Sec-Fetch-Site header, and Go 1.25 used it to add http.CrossOriginProtection to the standard library, a CSRF defense without any token. Fiber v3.6.0 brings the same check to Fiber as csrf.NewCrossOriginProtection (#4596). It sets no cookie, needs no storage and puts nothing in your templates.

This post protects a small notes service that has three kinds of clients: its own pages, a dashboard on a sibling subdomain, and an identity provider that posts back after login. We will exempt the one route that has to accept cross-site posts, roll the check out in report-only mode next to the existing tokens, pin the policy down in a test, and look at the cases where a token remains the better tool. Everything was built and tested against Fiber v3.6.1. The middleware needs v3.6.0 or later, which in turn requires Go 1.26.