Go (Golang) penetration testing: Security assessment for Go microservices

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

What makes Go security assessments different

Go microservices lack the built-in security scaffolding that frameworks like Django or Rails provide. There is no ORM with automatic parameterization, no built-in CSRF middleware, and no standard session library. Every security control is either a dependency or a custom implementation. This gives our security assessments a broader scope: we are testing not just configuration choices but the correctness of security-critical code that the developer wrote from scratch.

1. Concurrent request race conditions

Go's concurrency model using goroutines creates race conditions that are exploitable in financial applications. The classic exploitable race in payment systems is the time-of-check to time-of-use (TOCTOU) flaw: reading the balance, comparing against the requested amount, and then decrementing in three separate operations that are not atomic:

// VULNERABLE pattern: balance check and deduction not in a transaction
func Transfer(userID, amount int) error {
    balance := db.GetBalance(userID)   // Read
    if balance < amount {             // Check
        return errors.New("insufficient funds")
    }
    db.Deduct(userID, amount)          // Use
    // Race: two goroutines can pass the balance check simultaneously
    return nil
}

We test for this by sending concurrent requests during the assessment, observing whether multiple transactions succeed when only one should have been permitted. This is the same methodology we use for Nigerian fintech race conditions on NIBSS pending transactions.

2. JWT and authentication middleware

Go JWT libraries (golang-jwt, dgrijalva/jwt-go) have a history of the algorithm confusion vulnerability. We test whether your JWT verification middleware accepts tokens signed with the none algorithm, and whether the middleware correctly validates the alg header against the expected algorithm before processing the signature. We also test for middleware that is registered but not applied to all routes that require protection.

3. Database injection via GORM and sqlx

We audit every database interaction for raw query construction. GORM's default query builder is safe, but Raw() and Exec() methods accept format strings. We test every raw query path with SQL injection payloads and verify that parameterized placeholders are used consistently.

4. HTTP handler input validation

Go HTTP handlers receive raw http.Request objects. There is no automatic input binding or validation. We test for missing input validation on query parameters, JSON body fields, and path parameters. Common findings are missing integer range checks (allowing negative amounts or amounts exceeding business limits), missing string length limits (allowing extremely large payloads that block the event loop), and missing field requirement checks (allowing null pointer dereferences through uninitialized struct fields).

Related reading

Blog: Go Gin and Fiber security audits · NIBSS race conditions · JWT token mistakes

Services: Penetration testing · API security testing