Go Security in Production on Atharva Pandey

Lesson 9: Dependency Scanning — govulncheck before you deploy

Mon, 05 May 2025 00:00:00 +0000

The security posture of your Go application is not just about the code you write — it is also about the code you import. A typical Go microservice will have dozens of direct and transitive dependencies. Any one of them might have a known vulnerability in the specific version you are using. Unlike the bugs in your own code, these vulnerabilities are publicly catalogued, exploits are often published, and attackers scan for them at scale.

Lesson 8: Secure HTTP Defaults — Your production server needs these headers

Mon, 10 Mar 2025 00:00:00 +0000

When I run the Go HTTP server in the standard library with no configuration, it does a lot of things right — it is fast, it handles HTTP/2, it is well-tested. But it also does a handful of things that are wrong for production: no timeouts, no response headers that protect against common browser-based attacks, and server identification information in responses. These are not bugs in the standard library; they are defaults appropriate for development that need to be changed before you deploy.

Lesson 7: JWT Caveats — JWTs are not sessions

Sat, 18 Jan 2025 00:00:00 +0000

JWT has become the default answer to “how should I handle authentication tokens?” in the Go community. I have shipped JWTs in production and I have also shipped systems that would have been much simpler and more secure with server-side sessions. The point of this lesson is not that JWTs are bad — it is that they carry specific security risks that are easy to overlook, and they solve a specific problem (stateless authentication across services) that not every application actually has.

Lesson 6: Password Hashing — bcrypt or argon2, nothing else

Mon, 02 Dec 2024 00:00:00 +0000

Password hashing is one of those topics where the correct answer is short and clear, the wrong answers are numerous and subtle, and developers who confidently implement one of the wrong answers often do not know they did anything wrong until a database is leaked and journalists start writing about it. I have sat in a post-mortem where the words “we were using MD5” were spoken in a conference room full of very quiet people. That was not my code, but I understood how it happened — MD5 was the “hash function” the developer knew, and they did not realize it was entirely unsuitable for passwords.

Lesson 5: Auth Middleware — Authentication is not authorization

Tue, 22 Oct 2024 00:00:00 +0000

A few years ago I audited a Go API where every endpoint was protected by an authentication middleware. The middleware checked for a valid JWT, extracted the user ID, and set it in the request context. The developer was proud of it — every route was secured. The problem was that the product had a concept of “organizations” — users belonged to organizations — and the API let you fetch any organization’s data as long as you were authenticated. The authentication was solid. The authorization was completely absent.

Lesson 4: SSRF and Injection — The URL your user gave you might be localhost

Wed, 18 Sep 2024 00:00:00 +0000

I reviewed a Go service that let users provide a “webhook URL” — we would call that URL when their account had a notification. The service fetched a preview of the URL to display in the UI. The developer who built it figured that since it only fetched the URL and never executed what was returned, it was safe. They had not considered that http://169.254.169.254/latest/meta-data/iam/security-credentials/ is also a URL.

SSRF — Server-Side Request Forgery — is the class of vulnerability where an attacker tricks your server into making an HTTP request to a target of their choosing, typically to access internal services that are not exposed to the internet. AWS instance metadata, Redis, internal Kubernetes API servers, admin dashboards, other services in your VPC — all are reachable from a server that blindly follows user-supplied URLs.

Lesson 3: TLS Configuration — Your default HTTP server is unencrypted

Mon, 12 Aug 2024 00:00:00 +0000

When I started writing Go HTTP servers, I thought TLS was someone else’s problem. A load balancer in front of my service handled HTTPS termination, so my service only ever spoke plain HTTP on the internal network. That is a common and often defensible architecture. But it means that if anyone gains access to your internal network — a compromised service, a misconfigured cloud security group, a rogue container — all traffic between your services is plaintext. I learned this lesson not from a breach but from a penetration test report that listed it as a finding with a crisp paragraph explaining exactly why it mattered.

Lesson 2: Secret Handling — Env vars are not a vault

Mon, 08 Jul 2024 00:00:00 +0000

I once found database credentials committed directly in a Go source file — not in a toy project, in a staging environment of a real product. The developer who wrote it knew it was wrong, but they were “just testing” and forgot to revert it. That file lived in the repository for eight months before anyone noticed. By then, the credentials had been rotated, but the history was permanent.

Secret handling in Go is not primarily a coding problem. It is a discipline problem. The code patterns are simple. The failures happen when you treat secrets as a detail to clean up later, or when you assume that environment variables are inherently safe because they are not in source code.

Lesson 1: Input Validation — Trust nothing from the wire

Wed, 05 Jun 2024 00:00:00 +0000

The first production security incident I dealt with involved a simple integer field in a JSON body. The client sent a negative number where we expected a positive quantity. We hadn’t validated it. The result was a negative charge on a purchase — we were effectively paying customers money. That taught me more about input validation than any security course.

Every byte that arrives over the wire is adversarial by default. Not because every user is malicious, but because your assumptions about the data are not enforced by anything except your own code. HTTP gives you a byte stream. JSON decoding gives you Go values. Neither of those steps checks whether the values make sense for your business logic. That job is yours.