DEV Community: TechTz Academy

Your API works in curl but not in the browser — that's CORS

TechTz Academy — Fri, 25 Sep 2026 19:47:05 +0000

You built an API. You tested it with curl and every endpoint answered perfectly. Then you pointed a front end at it and got this:

Access to fetch at 'http://localhost:8080/api/login' from origin
'http://localhost:5173' has been blocked by CORS policy: Response to
preflight request doesn't pass access control check.

Nothing is broken. Your API is fine. curl was never the test.

I hit this building a Vue front end for a Go helpdesk API, so here is what is actually happening and the middleware that fixes it — no library.

curl is not a browser

curl sends your request and hands you the reply. It does not care where the request came from, because curl has no concept of a page that made it.

A browser does. It knows the JavaScript calling fetch came from http://localhost:5173, and it knows you're calling http://localhost:8080. Different port means different origin, and by default a page may only call its own origin.

This rule exists for a good reason. Without it, any site you visited could quietly call yourbank.com/api/transfer using the cookies already in your browser. The block is protecting the user, not inconveniencing you.

So CORS — Cross-Origin Resource Sharing — is the mechanism by which a server says "it's fine, I know about that origin, let them through."

Two things follow from that, and they're the two things people get wrong.

The permission comes from the server, not the client. You cannot fix CORS in your front-end code. Every "fix" you find that involves changing fetch options is either wrong or a proxy in disguise.

The browser enforces it, not the server. The request often reaches your API and your API often answers. The browser then throws the answer away before your JavaScript sees it. That's why your server logs show a perfectly normal 200 while the console shows a failure. Deeply confusing the first time.

The preflight

For a simple GET, the browser sends the request and checks the reply for permission.

For anything else — POST with JSON, PATCH, DELETE, or any request with an Authorization header — it asks first. This is the preflight: an OPTIONS request to the same URL, saying "I'm from this origin, I want to use this method, I want to send these headers — may I?"

Your server must answer that OPTIONS request with permission headers. If it doesn't, the real request is never sent at all.

This is why people are baffled that their GET works and their POST doesn't.

The middleware

Here's the whole thing in Go, standard library only:

func withCORS(allowed []string, next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        origin := r.Header.Get("Origin")

        if origin != "" && originAllowed(origin, allowed) {
            w.Header().Set("Access-Control-Allow-Origin", origin)
            // the reply changes with the Origin, so caches must key on it
            w.Header().Add("Vary", "Origin")
            w.Header().Set("Access-Control-Allow-Methods",
                "GET, POST, PATCH, DELETE, OPTIONS")
            w.Header().Set("Access-Control-Allow-Headers",
                "Authorization, Content-Type")
            w.Header().Set("Access-Control-Max-Age", "86400")
        }

        // a preflight is answered here and never reaches a handler
        if r.Method == http.MethodOptions {
            w.WriteHeader(http.StatusNoContent)
            return
        }

        next.ServeHTTP(w, r)
    })
}

Wrap your router with it:

func (a *App) routes() http.Handler {
    mux := http.NewServeMux()
    // ... all your routes ...
    return withCORS(a.AllowOrigins, logRequests(mux))
}

Four details in there are worth spelling out.

Access-Control-Allow-Headers must list Authorization. This is the single most common cause of "I added CORS and it still doesn't work." If your API uses a bearer token and this header doesn't mention Authorization, the browser refuses to send the token and every authenticated call fails.

Echo the origin, don't hardcode one. Reflecting the caller's origin — after checking it's allowed — lets one deployment serve several front ends.

Vary: Origin is not optional. Your response now differs depending on who asked. Without this header a cache can store the reply for one origin and serve it to another, producing failures that only appear in production and only sometimes.

Max-Age stops the preflight tax. Without it the browser preflights every POST. With it, it asks once a day.

Never use `*`

Every tutorial shows Access-Control-Allow-Origin: *. It works, and it means any website on the internet may call this API.

For a public read-only API that's fine. For anything with authentication it is not — and the browser knows it, which is why * is simply ignored when credentials are involved.

Take the allowed origins from configuration instead:

origins := strings.Split(getenv("ALLOW_ORIGINS", "http://localhost:5173"), ",")

Localhost in development, your real domain in production, same code.

Test it without a browser

You don't have to guess. Send the preflight yourself:

curl -i -X OPTIONS localhost:8080/api/login \
  -H 'Origin: http://localhost:5173' \
  -H 'Access-Control-Request-Method: POST'

You want:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http://localhost:5173
Access-Control-Allow-Methods: GET, POST, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type
Vary: Origin

That is exactly what the browser does before every POST. If this works, the browser will too.

And because it's just headers, you can test it automatically:

func TestCORS(t *testing.T) {
    srv := newTestServer(t)
    const allowed = "http://localhost:5173"

    req, _ := http.NewRequest("OPTIONS", srv.URL+"/api/login", nil)
    req.Header.Set("Origin", allowed)
    res, _ := http.DefaultClient.Do(req)

    if res.StatusCode != http.StatusNoContent {
        t.Errorf("preflight status: got %d, want 204", res.StatusCode)
    }
    if got := res.Header.Get("Access-Control-Allow-Origin"); got != allowed {
        t.Errorf("allow-origin: got %q, want %q", got, allowed)
    }

    // an origin we did not allow must get nothing
    req2, _ := http.NewRequest("OPTIONS", srv.URL+"/api/login", nil)
    req2.Header.Set("Origin", "http://evil.example")
    res2, _ := http.DefaultClient.Do(req2)

    if got := res2.Header.Get("Access-Control-Allow-Origin"); got != "" {
        t.Errorf("unknown origin was allowed: %q", got)
    }
}

That second half matters more than the first. It's easy to write CORS middleware that allows everything by accident, and a test that only checks the happy path will happily pass.

The one that catches everyone in production

Your front end works locally. You deploy it. It breaks.

ALLOW_ORIGINS is still set to localhost. Set it to your real domain.

And while you're there: if your front end uses client-side routing, tell your static host to serve index.html for unknown paths, or refreshing /tickets/1 gives a 404. Different problem, same deployment day, equally annoying.

Full code

All of this is from a real project — a helpdesk API in Go with JWT auth and a Vue 3 front end, both free:

https://github.com/Abbysifuni/helpdesk-api

I also walked through building it end to end on video. The API series is here:

Build a real helpdesk ticket API with Go, SQLite and JWT, step by step in 8 short parts: project setup, database, user accounts, login, tickets, comments, te...

youtube.com

And the Vue front end, including this CORS work:

Build a real Vue 3 front end for the Go helpdesk API, in 5 short parts: Vite setup and CORS, JWT login with route guards, the ticket list with filters, ticke...

youtube.com

If CORS has bitten you somewhere I haven't covered, tell me in the comments — the failure modes are weirdly varied and I'd like to collect them.

I built a real Helpdesk API in Go — no framework, just the standard library

TechTz Academy — Fri, 25 Sep 2026 17:23:14 +0000

Most "build an API in Go" tutorials stop at a /hello route. This one goes all the way to something you could actually put behind a support desk: accounts, hashed passwords, JWT login, role permissions, filters, automated tests and a Docker image.

The whole thing uses net/http and database/sql from the standard library, plus exactly two dependencies: a SQLite driver and a JWT library. No Gin, no Echo, no ORM.

All the code is here: https://github.com/Abbysifuni/helpdesk-api

Here is what it does and the decisions that mattered, with the full video walkthrough at the end.

What we're building

A ticket system with two kinds of users:

Customers register, open tickets and comment on their own tickets.
Agents see every ticket, change status and priority, assign tickets to themselves and delete them.

Tickets have a status (open, in_progress, resolved, closed) and a priority (low, medium, high). Everything lives in a single SQLite file.

Routing without a framework

Go 1.22 added method and wildcard patterns to http.ServeMux, and that removed most of the reason people reached for a router library. The entire routing table:

func (a *App) routes() http.Handler {
    mux := http.NewServeMux()

    mux.HandleFunc("GET /health", a.health)
    mux.HandleFunc("POST /api/register", a.register)
    mux.HandleFunc("POST /api/login", a.login)

    mux.Handle("GET /api/me", a.auth(a.me))
    mux.Handle("POST /api/tickets", a.auth(a.createTicket))
    mux.Handle("GET /api/tickets", a.auth(a.listTickets))
    mux.Handle("GET /api/tickets/{id}", a.auth(a.getTicket))
    mux.Handle("PATCH /api/tickets/{id}", a.auth(a.updateTicket))
    mux.Handle("DELETE /api/tickets/{id}", a.auth(a.deleteTicket))
    mux.Handle("POST /api/tickets/{id}/comments", a.auth(a.addComment))
    mux.Handle("GET /api/tickets/{id}/comments", a.auth(a.listComments))

    return logRequests(mux)
}

r.PathValue("id") reads the wildcard. a.auth(...) is the middleware that turns a handler into an authenticated one — more on that below.

Handlers hang off an App struct instead of package-level globals:

type App struct {
    DB         *sql.DB
    Secret     []byte
    AgentEmail string
}

That one change is what makes the tests easy later — you can build an App pointing at an in-memory database and the handlers neither know nor care.

Passwords: PBKDF2 from the standard library

Go 1.24 moved PBKDF2 into crypto/pbkdf2, so hashing passwords no longer needs golang.org/x/crypto. The stored format is Django-style, so the iteration count travels with the hash and you can raise it later without breaking old accounts:

const hashIterations = 600_000 // OWASP recommendation for PBKDF2-SHA256

// hashPassword returns "pbkdf2_sha256$iterations$salt$hash".
func hashPassword(password string) (string, error) {
    salt := make([]byte, 16)
    if _, err := rand.Read(salt); err != nil {
        return "", err
    }
    key, err := pbkdf2.Key(sha256.New, password, salt, hashIterations, 32)
    if err != nil {
        return "", err
    }
    b64 := base64.RawStdEncoding.EncodeToString
    return fmt.Sprintf("pbkdf2_sha256$%d$%s$%s", hashIterations, b64(salt), b64(key)), nil
}

Verification splits the stored string back apart and compares with subtle.ConstantTimeCompare, never ==. A plain string comparison leaks timing information about how many bytes matched.

One more small thing that matters: a wrong email and a wrong password return the same 401 with the same message. Different errors tell an attacker which emails are registered.

The auth middleware

func (a *App) auth(next authedHandler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        tokenStr, ok := strings.CutPrefix(r.Header.Get("Authorization"), "Bearer ")
        if !ok {
            writeError(w, http.StatusUnauthorized, "missing token")
            return
        }
        token, err := jwt.Parse(tokenStr, func(t *jwt.Token) (any, error) {
            return a.Secret, nil
        }, jwt.WithValidMethods([]string{"HS256"}))
        if err != nil || !token.Valid {
            writeError(w, http.StatusUnauthorized, "invalid or expired token")
            return
        }
        sub, _ := token.Claims.GetSubject()
        id, _ := strconv.ParseInt(sub, 10, 64)
        u, err := a.getUser(id)
        if err != nil {
            writeError(w, http.StatusUnauthorized, "user not found")
            return
        }
        next(w, r, u)
    })
}

Two details worth copying:

jwt.WithValidMethods([]string{"HS256"}) is not optional. Without it, an attacker can hand you a token with "alg": "none" and the library will happily accept it. Pin the algorithm.

The middleware takes an authedHandler — func(w, r, User) — instead of stuffing the user into the request context. The user then arrives as a typed argument that the compiler checks, rather than an any you have to assert at the top of every handler.

404, not 403

When a customer asks for someone else's ticket, the obvious answer is 403 Forbidden. That's the wrong answer. A 403 confirms the ticket exists. Loop over the IDs and you've mapped how many tickets the system holds and which ones are real.

So the lookup scopes by user first, and anything the caller can't see is simply not found:

// customers only ever match their own rows
if user.Role != "agent" {
    query += " AND user_id = ?"
    args = append(args, user.ID)
}

403 is still the right status when a customer tries to do something they're not allowed to on a ticket they can legitimately see — closing is fine, reassigning is not.

Filters without SQL injection

GET /api/tickets?status=open&priority=high builds its WHERE clause dynamically, which is exactly where people start concatenating strings. Don't. Build the placeholders, collect the values:

query := "SELECT " + ticketCols + " FROM tickets WHERE 1=1"
args := []any{}

if s := r.URL.Query().Get("status"); s != "" {
    if !validStatus[s] {
        writeError(w, http.StatusBadRequest, "invalid status")
        return
    }
    query += " AND status = ?"
    args = append(args, s)
}

The user's input never becomes SQL. It becomes an argument. And the validStatus map means a junk filter gets a clear 400 instead of silently returning nothing.

Tests that actually exercise the API

httptest plus an in-memory SQLite database gives you a real server, real HTTP, real SQL, and it runs in seconds:

func newTestServer(t *testing.T) (*httptest.Server, *App) {
    db, err := openDB(":memory:")
    if err != nil {
        t.Fatal(err)
    }
    app := &App{DB: db, Secret: []byte("test-secret"), AgentEmail: "agent@test.com"}
    srv := httptest.NewServer(app.routes())
    t.Cleanup(srv.Close)
    return srv, app
}

One gotcha: with :memory:, each new connection gets its own empty database. Set db.SetMaxOpenConns(1) so the pool reuses a single connection and your tables don't vanish between queries.

The suite covers registration validation as a table-driven test, login and JWT, the full ticket lifecycle, and the permission rules from both sides — customer and agent.

Shipping it

A multi-stage Dockerfile builds with golang:1.24-bookworm and CGO_ENABLED=1 (the SQLite driver needs cgo), then copies the binary into debian:bookworm-slim, runs as a non-root user, and mounts /data as a volume so the database survives container restarts.

Config comes from environment variables — ADDR, DB_PATH, JWT_SECRET, AGENT_EMAIL — so nothing secret ends up in the image.

The full series

Eight parts, roughly ten minutes each, building the whole thing from an empty folder:

Plan & project setup
The database with SQLite
Registering users safely
Login with JWT
Tickets: create & list
Update, delete & comments
Testing the API
Docker, docs & deploy

Part 1 — Plan & Project Setup:

Watch the rest in order here:

Build a real helpdesk ticket API with Go, SQLite and JWT, step by step in 8 short parts: project setup, database, user accounts, login, tickets, comments, te...

youtube.com

Full source, README and tests: https://github.com/Abbysifuni/helpdesk-api

If you're still getting comfortable with Go itself, the 30-day beginner course that leads into this one is here: https://www.youtube.com/playlist?list=PLed_bc2kQ9LM

Happy to answer questions about any of the choices above in the comments — especially the 404-instead-of-403 one, which surprises people.

DEV Community: TechTz Academy

Your API works in curl but not in the browser — that's CORS

curl is not a browser

The preflight

The middleware

Never use *

Test it without a browser

The one that catches everyone in production

Full code

I built a real Helpdesk API in Go — no framework, just the standard library

What we're building

Routing without a framework

Passwords: PBKDF2 from the standard library

The auth middleware

404, not 403

Filters without SQL injection

Tests that actually exercise the API

Shipping it

The full series

Never use `*`