What is the AWSALBCORS cookie?
This cookie is used by Amazon Web Services to maintain session stickiness across cross-origin requests, ensuring that subsequent user actions are consistently routed to the same back-end server behind the Application Load Balancer.
Table of Contents
About AWSALBCORS
| Vendor | Amazon Web Services |
|---|---|
| Category Category The functional category of the technology, such as Web Analytics or Social Media. Learn more | Heatmap & Recording |
| Consent Category Consent Category The consent category this cookie most commonly falls under across sites we scan, normalized into four standard categories. Learn more | Strictly Necessary |
| Prevalence | Very Common |
| Popularity Popularity Popularity is calculated from our dataset of 4.5B+ cookies analyzed across hundreds of millions of web pages. Learn more | Found on 20.5% of scanned pages |
| Expiration Type | Timestamp |
| Expiration Duration | 7 days |
| Party Type Party Type Whether the cookie is first-party or third-party. Learn more | Mixed |
| Risk Level Risk Level Rates how sensitive the data stored by this cookie is (High, Medium, or Low) based on data classification and distribution. Learn more | Low |
| Vendor Privacy Policy | https://aws.amazon.com/privacy/ |
| Vendor Website | https://aws.amazon.com/ |
What is the purpose of AWSALBCORS?
The AWSALBCORS cookie is a persistent infrastructure cookie established by the Amazon Web Services (AWS) Elastic Load Balancing service to enable session stickiness (affinity) for applications utilizing Cross-Origin Resource Sharing (CORS). It exists to guarantee that sequential asynchronous requests initiated by a web browser from a third-party context or dynamic frame are consistently mapped and routed to the same back-end server instance behind the Application Load Balancer (ALB). This prevents data degradation, loss of active state, or unexpected session terminations that would otherwise occur if subsequent cross-origin API calls were distributed randomly across different server nodes.
The cookie carries an encrypted and obfuscated routing payload generated directly at the network layer. This payload contains structural information regarding the target server pool and specific instance mappings, alongside a cryptographic signature to verify the data's integrity and prevent client-side tamper attempts. It does not store or transmit any personally identifiable user information (PII) or application-level session states, operating strictly as a transient network routing directive.
What are the Privacy Risks of AWSALBCORS?
Risk Level: Low
The AWSALBCORS cookie is classified as Low risk because its operational scope is strictly confined to network infrastructure layer routing and traffic load balancing. Official technical specifications from Amazon Web Services confirm that the cookie contains only an encrypted routing payload used to maintain session affinity (stickiness), ensuring that cross-origin API calls are reliably directed to the same back-end server instance to preserve active application states.
It does not capture, track, or aggregate user browsing history, behavioral metrics, or commercial identifier patterns usable for cross-site profiling or target marketing. Because its deployment is entirely functional, contains zero client-side Personally Identifiable Information (PII), and performs an architecture utility equivalent to a temporary server session ID, it strictly satisfies the Low risk tier criteria.
How to Remove AWSALBCORS from a Website
To remove the AWSALBCORS cookie from a website, a network administrator or cloud architect must log into the Amazon Web Services (AWS) Management Console, navigate to the EC2 or EC2 Image Builder dashboard, and access the specific Application Load Balancer (ALB) configuration. Under the attributes section of the target group assigned to the balancer, the operator must explicitly disable the "sticky sessions" (session affinity) feature. Because this cookie is injected directly at the infrastructure level by the AWS Elastic Load Balancing layer rather than by frontend application scripts, it cannot be disabled via client-side code modification or tag management updates; turning off target group stickiness within the AWS environment is the only way to completely prevent the infrastructure from issuing this routing identifier.