Protecting your APIs

1. Protecting your APIs

Welcome back! In this video, we will explore securing APIs on AWS.

2. Securing APIs on AWS

Securing APIs is a critical part of building cloud-native applications. APIs commonly expose sensitive business functionality and often act as the public entry point to back-end systems. Amazon API Gateway supports several approaches that help developers securely expose APIs to clients.

3. Authorization and authentication

Authentication is who you are. Authorization is what you can do.

4. IAM authorization

API Gateway can use AWS Identity and Access Management (IAM) for authentication and authorization. API Gateway secures APIs using AWS Signature Version 4 (SigV4). Clients sign every request; API Gateway validates the signature before processing. IAM policies then control what each identity can invoke. This model is best suited for internal AWS service-to-service communication where SigV4 signing is natively supported.

5. Amazon Cognito authorizers

API Gateway also supports Amazon Cognito authorizers. Cognito allows developers to authenticate users using JSON Web Tokens (JWTs). This is commonly used for securing APIs in mobile applications, web applications, and user sign-in workflows. Cognito also supports federation with external identity providers such as Google, Facebook, Apple, and enterprise providers using SAML or OpenID Connect (OIDC). This means that API Gateway can validate JWT tokens natively without requiring custom authentication code or Lambda authorizers.

6. Lambda authorizers

Lambda authorizers implement custom authentication and authorization logic using a Lambda function, which returns an IAM policy allowing or denying access to the API. Lambda authorizers can validate custom tokens, integrate with external identity providers, or enforce custom authorization rules.

7. Lambda authorizers

A common example is validating a JWT token issued by a third-party identity provider such as Auth0. When a request arrives, API Gateway invokes the authorizer Lambda before forwarding the request to the back-end. The function validates and decodes the token, then returns an IAM policy allowing or denying access. If valid, the request proceeds; otherwise API Gateway immediately returns a 401 response.

8. Which authorizer

Use Cognito Authorizer for user-facing applications where you want managed sign-up, sign-in, and token validation without writing custom code. Use Lambda Authorizer when you need custom logic, are integrating with a third-party identity provider, or have authorization rules that go beyond what Cognito supports natively.

9. Authorizer caching

Authorizer responses are cached reducing latency and cost on frequently called endpoints. Cache TTL is configurable between 0 and 3600 seconds, with 300 as default and 0 disabling caching.

10. API Gateway resource policies

Resource policies allow developers to control which AWS accounts, IP ranges, or VPCs can access an API. Policies are used to restrict internal APIs, enforce network-based access controls, and limit API exposure.

11. Encryption

API Gateway automatically supports HTTPS endpoints using TLS encryption. HTTPS encrypts data in transit between clients and API Gateway, protecting sensitive information from interception. API Gateway also integrates with AWS Certificate Manager (ACM) to manage SSL/TLS certificates for custom domain names. ACM certificates for custom domains are free. Do NOT expose APIs over unencrypted HTTP connections.

12. Mutual TLS (mTLS)

API Gateway supports mutual TLS for client certificate authentication. This requires a configured custom domain name. This is commonly used for machine-to-machine communication where both parties need to verify each other's identity.

13. API throttling and rate limiting

Throttling helps protect back-end systems and improves API reliability. Without protection, back-end services may become overloaded. Rate limits control steady requests per second, and Burst limits provide temporary traffic spikes allowed above the steady rate. When throttling limits are exceeded, API Gateway returns `429 Too Many Requests`

14. Protecting against common exploits

Attaching AWS WAF to API Gateway blocks malicious requests before they reach your API, including SQL injection attempts, cross-site scripting (XSS), and traffic from known malicious IP ranges.

15. Usage plans and API keys

Usage plans and API keys allow developers to control how clients consume APIs. You can configure request quotas, define rate limits, and subscription tiers. Different customers or applications can be assigned different API consumption limits.

16. Cross-Origin Resource Sharing (CORS)

CORS permits browsers to make cross-origin API requests from approved domains and client applications. Without CORS configuration, browser requests may be blocked even if the API itself is functioning correctly. Overly permissive CORS configurations can introduce security risks. Avoid setting Access-Control-Allow-Origin: * in production as this permits any domain to call your API. Always restrict CORS to known, trusted origins.

17. CORS headers and preflight requests

Preflight is a check sent before the real request (OPTIONS), confirming the API permits cross-origin access. API Gateway adds a number of response headers to support CORS. These are returned automatically by API Gateway for Non-Proxy integrations. When using Proxy integrations, the Lambda function itself must return the CORS headers and preflight, not API Gateway.

18. Let's practice!

Now it's time to test your knowledge of securing your APIs.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.