LAA-Software-Engineering/golang-rest-api-template

Summary The CORS middleware sets AllowCredentials: true together with wildcard AllowMethods: ["*"] and AllowHeaders: ["*"]. Per the Fetch/CORS spec, * is not treated as a wildcard when the request is credentialed — the browser interprets it literally — so credentialed cross-origin requests that use a real method (PATCH/DELETE/PUT) or any custom header (the app's own X-API-Key, Authorization) fail the preflight. Where pkg/middleware/cors.go: return cors.New(cors.Config{ AllowOrigins: []string{"http://127.0.0.1", "http://127.0.0.1:8001", "http://localhost", "http://localhost:8001"}, AllowMethods: []string{"*"}, AllowHeaders: []string{"*"}, AllowCredentials: true, MaxAge: 12 * time.Hour, }) gin-contrib/cors emits these verbatim as Access-Control-Allow-Methods: * and Access-Control-Allow-Headers: * (see the library's utils.go), alongside Access-Control-Allow-Credentials: true. Why it's a bug Every mutating route in this API requires X-API-Key,

Summary The PostgreSQL connection string is assembled by raw string interpolation of the POSTGRES_* environment variables. Any special character in POSTGRES_PASSWORD (or POSTGRES_USER, POSTGRES_DB, host, port) breaks parsing/connection or, worse, silently changes where the client connects — because the values are never URL-encoded. Where pkg/database/db.go — NewDatabase: dbURL := fmt.Sprintf("postgres://%s:%s@%s:%s/%s", db_user, db_pass, db_hostname, db_port, db_name) cfg, err := pgxpool.ParseConfig(dbURL) Root cause postgres://user:pass@host:port/db is a URL. The userinfo and path components must be percent-encoded, but the values are dropped in verbatim. Characters that routinely appear in generated/strong passwords have URL meaning: @ → splits userinfo from host, so pass=foo@bar makes pgx try to connect to host bar. : → splits password from port / user from password. / ? # → start path / query / fragment. space and other reserved chars → ParseConfig errors or misparses.

Summary GET /books returns HTTP 500 whenever Redis is unavailable, even though Postgres is healthy and the data could be served directly. A Redis outage takes down the entire book-read path instead of degrading gracefully to an uncached database read. Where pkg/service/book_service.go — ListBooks (the s.redis.Set(...) branch inside the singleflight closure) Wiring: cmd/server/main.go → cache.NewRedisClient() → api.NewRouter → service.NewBookService Root cause NewBookService is documented as treating Redis as optional: "a nil redis disables list caching." But in production wiring the Redis client is created with redis.NewClient(opts), which is lazy and never nil — it returns a non-nil *redis.Client even when the server is unreachable. So s.redis != nil is always true and ListBooks always takes the caching path. Inside that path, a cache read miss is tolerated (any Get error is treated as a miss and falls through to the DB), but a cache write failure is fatal: out, err, _ :=