Designing a secure REST API for a banking application means layering multiple defenses—transport security, strong authentication, strict authorization, input validation, and auditing—since financial data demands defense in depth rather than a single control.
Key Points: • Enforce HTTPS/TLS everywhere so credentials and financial data are never sent in plaintext. • Use OAuth2 for authentication/authorization and JWT for stateless, verifiable session tokens. • Apply fine-grained role-based or attribute-based authorization on every endpoint, not just at the gateway. • Keep CSRF protection enabled where session cookies are used, and validate all input to block SQL injection and other exploits. • Add centralized logging, monitoring, and alerting to detect and respond to suspicious activity quickly. • Consider rate limiting and account lockout policies to blunt brute-force and credential-stuffing attacks.
Example: A funds-transfer endpoint requires a valid JWT with a TRANSFER_FUNDS authority, validates the request body against strict schema rules, logs the request with a correlation ID, and runs entirely over TLS 1.2+.
Interview Tip: A concise interview answer is:
"For a banking REST API I'd combine HTTPS everywhere, OAuth2/JWT for authentication and authorization, strict role-based access control per endpoint, input validation to block injection attacks, and centralized logging and monitoring. No single control is enough for financial data, so it has to be defense in depth."