Networking & Content Delivery
Securing your web applications and optimizing their performance with AWS Application Load Balancer
Are you interested in securing your web applications and optimizing their performance to maintain a seamless user experience and safeguard against cyber threats? Application Load Balancers (ALBs) provide a powerful feature for modifying request and response headers, allowing you to fine-tune your application’s behavior in numerous ways. From bolstering security with essential headers such as Content Security Policy and HTTP Strict Transport Security, to enhancing performance through caching strategies and efficient resource delivery, ALBs offer a versatile toolkit for developers and system administrators. Whether you’re aiming to comply with industry standards, integrate with API gateways, or implement custom application logic, mastering header modification can significantly elevate your application’s robustness and efficiency. In this post, we explore a couple of these features and uncover how you can use ALB header modifications to supercharge your web applications on AWS.
Renaming TLS headers
One of the most requested use case is around header renaming. Some legacy systems are known to expect headers in specific formats, for example they may expect the header as “Custom-TLS” instead of “X-Amzn-TLS”. Renaming ALB-generated headers such as X-Amzn-mTLS and X-Amzn-TLS allows users to make sure of compatibility with legacy application code. This makes it easier to use all of the features that ALB has to offer without adding complexity or workarounds to their workflows. Moreover, this enables seamless integration with existing applications and provides the flexibility to adapt the ALB feature to specific organizational needs without changes to application code or backend services. For example:
aws elbv2 modify-listener-attributes \
—listener-arn <ARN> —attributes \
Key=[Headers From renaming headers section].header_name \
Value="desired_header_field_name"Renaming ALB-generated mTLS and TLS header fields, not the value, provides users with the ability to use header names that work with their existing TLS-related application code. Users can rename any of the TLS header fields using a listener attribute API call, or in the AWS console.
HTTP Strict-Transport-Security and cross-origin resource sharing
Another most requested use case is around inserting headers such as HTTP Strict-Transport-Security (HSTS) and cross-origin resource sharing (CORS) at the ALB level. This enables ALB users to meet critical security and compliance needs. HSTS header insertion helps users enhance security by enforcing HTTPS across all client connections, protecting against man-in-the-middle attacks, and making sure of compliance with industry regulations such as PCI DSS and HIPAA. One main benefit of this feature allows ALB users to meet security standards without changing the underlying application code. Similarly, inserting CORS headers allows for secure cross-origin resource sharing, enabling controlled access between different domains in modern web-applications. This streamlines the process of managing cross-origin policies across multiple services, making sure that only authorized credentials can access sensitive resources.
Insert security or CORS headers for cross-origin compliance:
aws elbv2 modify-listener-attributes \
--listener-arn <ARN> —attributes \
Key=routing.http.response."Headers From insert headers section".header_name \
Value="desired_value"Server header
Another critical security use case is disabling the server header, which is critical for organizations that have strict security and privacy policies mandated by PCI DSS. It makes sure that server information isn’t inadvertently exposed. ALB’s header modification allows you to disable the “Server” header in responses from the ALB. Furthermore, it reduces the exposure of server specific information, preventing automated scanning tools or attackers from exploiting identified vulnerabilities in specific server software. Centralized management at the ALB level allows organizations to uniformly apply the same security standard across applications, and streamlining security operations making sure of consistent protection.
This configuration can prevent the exposure of server info such as “awselb/2.0” in responses, offering an added layer of security:
ALB only adds the server header info with the value as awselb/2.0 when the target response has no server header in it. With the server header disable feature, users can have ALB not add the server header info in the response. If the target response already has a server header, then it is still proxied to the client.
Solution overview
To enable these features or use cases at scale, you can use the following solution, which queries ALBs in an AWS Region based on the tag provided, and modifies the headers of your choice for all the ALBs with that specific tag. This solution deploys an AWS Lambda function to modify ALB headers at scale. The solution can run multiple times by changing the Environment variables associated to Lambda.
Solution deployment
You can deploy this solution into your AWS account using an AWS CloudFormation template.
Prerequisites
For this walkthrough, you should have an AWS account.
Steps to deploy the CloudFormation template
- Download the YAML file.
- Navigate to the CloudFormation console in your AWS account.
- Choose Create stack.
- Choose Template is ready, upload a template file, and navigate to the YAML file that you just downloaded.
- Choose Next.
- Give the stack a name (max. length 30 characters), and choose Next.
- For the parameter “ALBAttributeName” enter the ALB Header that needs to be updated or added, for the parameter “ALBAttributeValue” enter a custom ALB Header that would be used instead of the default header, for the parameter “TagKey” enter the tag key that the solution uses to list ALBs, and for the parameter “TagValue” enter the tag value that the solution uses to list ALBs in region. These are optional parameters and can be set on the Lambda function.
- Add tags if desired, and choose Next.
- Scroll to Capabilities at the bottom of the screen, and check the box I acknowledge that AWS CloudFormation might create IAM resources with custom names, and then Create stack.
- Wait for the stack creation to complete.
When the CloudFormation template deploys the Lambda function, modify the environment variables of the Lambda function and run it to modify ALB headers as needed for all ALBs with in a Region with a specific tag.
Conclusion
The new ALB Header Modification features allow you to gain significant flexibility in managing HTTP headers: whether it’s renaming TLS-related headers for compatibility, disabling the server header for enhanced security, or inserting specific security-related headers to enforce compliance. You can use AWS CLI modify-listener-attributes command to manage this for individual ALBs, or use above solution to manage this at scale for ALBs in your account and region. These features empower administrators to fine-tune traffic management while maintaining security, and enabling seamless operations across complex cloud environments.