curl -I -o /dev/null -w "%{http_code}" https://example.com
HTTP 400 Bad Request indicates the server cannot or will not process the request because it appears malformed — invalid syntax, missing required fields, malformed JSON, oversized headers, invalid URL encoding. The request itself is the problem; retrying without changes will produce the same 400.
400 is the generic "client did something wrong" code. More specific codes (401 unauthorised, 403 forbidden, 404 not found, 422 validation error) are preferred when applicable. Returning 400 for everything client-error is a code smell — proper categorisation helps debugging and helps surrounding systems (monitoring, log analysis) interpret error patterns.
From a security perspective, 400 responses sometimes leak information about server-side parsing logic. Detailed error messages ("expected JSON field user_id of type integer at position 47") help debugging but tell attackers about your data structures and validation logic. Production responses should typically use generic error messages; detailed errors stay in logs accessible to operators only.
APIs validate incoming requests for required fields, correct types, value ranges, and business logic constraints. Failed validation returns 400 (or 422 for semantic validation specifically). Standard API pattern; well-designed APIs have consistent validation behaviour and helpful (but not over-detailed) error responses.
Forms validate inputs server-side (after client-side validation, which is convenience not security). Validation failures return 400 with field-level error indication. Modern frameworks render validation errors in the UI from the 400 response.
Pentest tools fuzz API endpoints with malformed inputs to discover error-handling vulnerabilities. 400 responses are normal; the interesting cases are when fuzzing produces 500 responses (indicating server-side crash on bad input — possible exploitable bug).
Hunters look for 400 responses that leak information: stack traces in error messages, internal file paths, database error details, framework versions. Each leak is potentially a valid bug bounty finding for security-conscious programs.
WAFs and API gateways frequently return 400 for requests that violate their rules (oversized headers, suspicious patterns, malformed payloads). The 400 originates from the gateway, not the application. Distinguish in logs whether 400s come from app validation or gateway rejection.
Stack traces leak internal application structure, framework versions, file paths, and sometimes data values. Configure environment-aware error responses: detailed in dev, generic in prod with correlation IDs to logs.
400 is generic client error. If the issue is authentication, use 401. If the issue is authorisation, use 403. If the issue is business validation specifically, 422 is more specific. Use the right code for the actual condition.
Error message like "Invalid value for field X: " with unsanitised user input in the message creates XSS in error responses. Always sanitise user input when echoed in any response, including error responses.
Generic errors in production protect from information leakage but make debugging hard if you cannot correlate user reports to log entries. Include a correlation ID in the response: "Error ID: abc123" — operators can look up the detailed error in logs by ID.
APIs that accept JSON should require Content-Type: application/json. Requests with wrong Content-Type or none at all should get 400 (or 415 Unsupported Media Type) rather than crashing the parser. Catch this at framework level.
CORS preflight (OPTIONS request) failures should follow CORS protocol — not 400 generally. Properly configured CORS handling is independent of generic request validation.
DEBUG = False in production. Rails: production environment by default. Express: error-handler middleware with environment check. Implement structured logging with correlation IDs so operators can look up production errors by ID.