Defensive API development techniques for Gophers

The talk argues that network controls, packet-inspecting firewalls and API gateways cannot fully remove risk once outside requests reach the application. It frames application-layer hardening for Go APIs as a team effort, where overlapping protections at different layers are acceptable.

A large part covers dependency hygiene. Go's standard library lets services avoid many third-party packages, but adopted libraries should be vetted for project age, release cadence, maintainer responsiveness and transitive dependencies. One case showed an unreleased library with a race condition, forcing a team to pin an untagged commit. Automated update tooling, linters and vulnerability scanners in the pipeline help keep components current. In code, demos showed a recovery handler that keeps the server running after a panic, and a goroutine panic that crashes the process unless it is recovered inside that goroutine. Request inspection covers allowed methods, Content-Type checks, body size limits and rejecting unknown JSON fields. Rate limiting backed by Redis shares state across instances. A fuzzing example on a string-reversing handler surfaced a UTF-8 bug, and JSON Schema constraints for length, pattern, format and enumeration were validated with a library.

The closing takeaways are to understand exposure at each layer, keep dependencies and toolchains updated, make APIs resilient through recovery and rate limits, inspect inputs strictly, fuzz business logic in non-production environments, and feed logs into threshold-based alerts.