Recently, we were adressing a pentest remediation plan. One of the finding was about the HTTP Host Header Injection. A web appliaction is hosted on a EC2 behind an AWS ALB. You can read more about: https://portswigger.net/web-security/host-header
HTTP Host Header injection vulnerability fix in AWS ALB
HTTP Host Header Injection vulnerabilities arise when web applications improperly process the value of the Host header, which can be fully controlled by the user. When a server implicitly trusts this header without properly validating or sanitising it, attackers can manipulate it to inject malicious payloads, potentially altering server-side behaviour. Such weaknesses can lead to a wide range of security issues. Notable examples include web cache poisoning, business logic abuse, routing-based server-side request forgery (SSRF), and even the exploitation of server-side vulnerabilities such as SQL injection.
An attacker may sometimes use alternative headers like X-Host, X-Forwarded-Server, X
HTTP-Host-Override, forwarded, or rewritten to inject malicious input, bypassing any validation on the
Host header itself.
HTTP Request:
HTTP/2 200 OK
Date: Tue, 16 Dec 2025 13:13:12 GMT
Content-Type: text/plain
Content-Length: 43
Cache-Control: no-cache
Pragma: no-cache
Expires: -1 HTTP response:
GET /xxx/xxx/xxxxx HTTP/2
Host: xxxxxxxxxx.pentestcontrolleddomain.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:145.0) Gecko/20100101 Firefox/145.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailersHTTP Host Header injection vulnerability fix in AWS ALB
We have already seen this finding on Apache, Nginx but we didn’t mitigate such finding yet on AWS ALB.
First, we tried to reproduce it, by using curl and adding an header:
curl --header 'Host: a.example' -v https://url.comCurrently by adding or not the option –header, we always get a HTTP 200.
We will modify this setting by using the AWS web console. Go to “Load balancing”, click on the “load balancer” instance and then “Listeren and Rules” then “Managed Rules” and Add Rules (dropdown menu on middle left).
We add a first rule (priority 1) to check the host header (and define the host such as mydomain.com). A second rule (last default) is responding with a 503.
Validate, try again the curl command and you will now see the difference with and without the added header.
Regarding the Security Policy, we recommend (06/2026) using the policy “ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09”. This Post-Quantum Crytography policy doesn’t include TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, which is considered as “weak”.
The Importance of Penetration Testing After an Application Migration
Application migration—whether to a new infrastructure, cloud environment, or modernised architecture—is a critical step in any organisation’s digital transformation. However, while migrations are often driven by performance, scalability, or cost optimisation objectives, they also significantly reshape the organisation’s attack surface. As a result, conducting a penetration test after migration is not optional—it is a fundamental requirement to ensure that the new environment is secure.
1. A Migration Changes the Entire Security Landscape
An application migration is not merely a technical relocation. It introduces changes at multiple levels: infrastructure, network configuration, identity and access management, APIs, and integrations. These changes can fundamentally alter how the application is exposed to threats.
In cloud environments in particular, the traditional perimeter-based security model disappears and is replaced by a more complex model based on configurations, identities, and services.
This transformation increases the risk that misconfigurations—such as open ports, excessive privileges, or insecure APIs—can unintentionally expose critical assets.
2. New Alarming Vulnerabilities Are Often Introduced
Even when a migration is carefully planned, it frequently introduces new vulnerabilities:
- Misconfigured access controls or IAM policies
- Insecure data transfers or insufficient encryption
- Weak authentication mechanisms
- Exposure of previously internal services
- Integration weaknesses with third-party services
- HTTP Host Header injection vulnerability
These are not theoretical risks. Migration projects can lead to security gaps or vulnerabilities that attackers can exploit if not properly assessed. Furthermore, cloud migrations can expose hidden vulnerabilities or create entirely new ones due to differences in architecture and configuration.
3. Assumption of Security Is a Critical Mistake
A common misconception is that moving to a cloud provider automatically increases security. In reality, organisations remain responsible for securing their applications, data, and configurations.
Without a dedicated security assessment, organisations may unknowingly carry over existing vulnerabilities—or even worsen them—into a more exposed environment. This creates a false sense of security that can lead to serious incidents, including data breaches or service compromise.
4. Penetration Testing Validates Real-World Security
Unlike traditional audits or automated scans, penetration testing simulates real-world attacks. It provides a practical assessment of how an attacker could exploit vulnerabilities in the migrated environment.
After migration, a penetration test allows organisations to:
- Identify exploitable vulnerabilities before attackers do
- Validate the effectiveness of security controls
- Test the resilience of authentication, authorisation, and network segmentation
- Detect cloud-specific risks such as exposed storage or insecure APIs
This proactive approach ensures that security weaknesses are addressed before they can be leveraged in real attacks.
5. Ensuring Business Continuity and Compliance
Security incidents following a migration can have severe consequences, including operational disruption, data loss, regulatory penalties, and reputational damage.
Post-migration testing—including penetration testing—is essential to verify that:
- Data has been securely transferred and remains protected
- Regulatory requirements (e.g., GDPR, ISO 27001) are respected
- Critical business functions remain secure and operational
Skipping post-migration security testing can result in vulnerabilities that disrupt operations and lead to costly remediation efforts.
6. Continuous Testing Is Part of a Mature Security Strategy
Migration should not be viewed as a one-time event but as part of a continuous evolution of the IT environment. Each change—new features, integrations, or infrastructure updates—can introduce new risks.
Therefore, penetration testing after migration should be considered the first step in an ongoing security lifecycle, complemented by regular re-testing and monitoring to maintain a strong security posture.
Conclusion
An application migration is a high-impact event that reshapes both the architecture and the risk exposure of an organisation. While it enables innovation and efficiency, it also introduces new vulnerabilities and uncertainties.
Penetration testing is the most effective way to validate the security of the migrated environment under realistic conditions. It provides organisations with the assurance that their systems are not only functional but also resilient against cyber threats.
In today’s threat landscape, launching a migrated application without a thorough penetration test is equivalent to going live without knowing whether the environment is secure. For organisations that value confidentiality, integrity, and availability, post-migration pentesting is not just recommended—it is essential.
See our portfolio of pentests, specially for web applications.