Input-Validation

Right, let’s talk about making your code less of a liability. You’ve written it, it compiles, and the tests pass. Great. But is it secure? Or did you just accidentally create a delightful little Rube Goldberg machine for an attacker? This is where static analysis tools come in—they’re the nitpicky, hyper-vigilant friend who reads the terms and conditions so you don’t have to. We’re going to look at the big three in the Go ecosystem: go vet, staticcheck, and gosec. They overlap in places, but each brings its own unique flavor of paranoia to the party.

Right, let’s talk about secrets. You know, the things that, if they get out, turn your expensive cloud bill into someone else’s very expensive free crypto-mining rig. We’ve all seen the GitHub repo with AWS_ACCESS_KEY_ID="AKIAIMNOTTELLINGYOU" committed three years ago and never rotated. Don’t be that person. Managing secrets is arguably more about discipline than technology, but since this is a Go book, we’ll focus on how the technology can save you from yourself.

Alright, let’s talk about JWTs. You’ve probably seen these things everywhere, the bearer tokens that look like a string of gibberish separated by dots. They’re a decent standard, but oh boy, the number of ways you can shoot yourself in the foot with them is truly impressive. I’ve seen more production fires started by bad JWT handling than by a toddler with a flamethrower. So let’s do it right. First, a brutal truth: you are not just “parsing” a JWT. You are validating it. Any library that just decodes that thing and hands you back a JSON object without so much as a “how do you do?” is a trap. Treat it like a suspect package. You must verify its contents, its authenticity, and its expiration before you even think about trusting what’s inside.

Right, let’s talk about password hashing. This is one of those things where if you get it wrong, you’re the person on the Hacker News post everyone clowns on. We don’t want that. You’re storing a secret the user entrusted to you, not a plaintext monument to your own laziness. So we’re going to do it properly, and in Go, that means reaching for golang.org/x/crypto/bcrypt. It’s the community’s battle-tested choice, and for good reason.

Right, let’s talk about making things unreadable on purpose. Hashing is the workhorse of crypto, and Go’s crypto package gives you a solid, if slightly opinionated, toolbox. We’re not encrypting here—we’re taking some data, scrambling it beyond all recognition, and getting a fixed-size fingerprint. The key idea is that you can’t reverse it. You can’t take the fingerprint and get the original data back. This is perfect for checking if a file has been tampered with or, more commonly, for safely storing passwords (though we’ll get to the massive caveats there in a second).

Look, TLS configuration is one of those things that separates the pros from the amateurs. It’s not enough to just slap tls.Config{} on your http.Server and call it a day. That’s like installing a vault door but leaving the key under the mat. The Go standard library gives you the tools to build a fortress, but it’s up to you to not build it with glaring weaknesses. Let’s get into the weeds.

Right, let’s talk about randomness. It’s the bedrock of almost everything secure you’ll do. Passwords, encryption keys, session tokens—you name it. If an attacker can guess it, you’ve already lost. So we need numbers that are truly, unpredictably random. Not the fake, predictable randomness you get from math/rand for shuffling your game’s card deck. We need the cryptographic-grade stuff. That’s what crypto/rand is for. Think of math/rand as a clever magician doing a card trick: it looks random to you, but it’s following a secret script (a seed). Anyone who knows the script knows the trick. crypto/rand, on the other hand, is pulling cards from a giant, chaotic deck being constantly shuffled by cosmic noise from your operating system. It’s fundamentally unpredictable.

Let’s be honest: most security vulnerabilities aren’t clever zero-days; they’re us, the developers, leaving the front door wide open with a welcome mat that says “PLEASE INJECT HERE.” The good news? In Go, slamming that door shut is often straightforward, provided you know which doors exist. We’re going to tour the most common ones and arm you with the tools to deadbolt them. SQL Injection: Your Query is Not a String Builder If you take one thing from this section, let it be this: never, ever concatenate user input directly into a SQL query. I don’t care how much you sanitize it in your head. Don’t do it. This isn’t a questionable design choice; it’s a cardinal sin.