Security defaults that belong in every Go HTTP server from day one — CORS, security headers, rate limiting, SQL injection prevention, input validation, secrets management, graceful shutdown, and request timeouts.
89
83%
Does it follow best practices?
Impact
99%
1.32xAverage score across 5 eval scenarios
Passed
No known issues
A small team is building a task management system and needs a Go HTTP API backed by a PostgreSQL database. The previous developer left a rough prototype that directly concatenates user input into SQL strings — the security team has flagged this as unacceptable. You need to rewrite it correctly.
The API also currently has the database password and JWT signing secret hardcoded in main.go. Before the code can be checked into the company's repository it needs to handle credentials safely.
Write a Go HTTP server in the ./taskapi/ directory that implements the following CRUD endpoints for tasks:
GET /api/tasks — list tasks, supports optional ?sort=created_at or ?sort=title query parameterGET /api/tasks/{id} — get a single task by integer IDPOST /api/tasks — create a task (JSON body: title string, description string)PATCH /api/tasks/{id} — update a task (JSON body: title string, completed bool)DELETE /api/tasks/{id} — delete a taskYou do not need a running database — use an in-memory slice to simulate the data store, but write all data access logic exactly as you would with database/sql and PostgreSQL (i.e., write the SQL query strings with proper placeholders and use a db object — you can mock or stub the actual sql.DB). The goal is to demonstrate correct query construction, not to run queries.
Write the server startup in a main.go that reads database connection string and JWT secret from the environment. Include a .env.example file listing the required environment variables.
Produce a SECURITY.md file that documents the security practices used in the implementation.