Solutions to overcoming 494 cloud-front cookie error

Question

we are using aws cloudfront to distribute our angular webapps to the web. We have this setup and configured so our webapps are live and can be accessed. However, due to the need to allow for authentication across these apps we have implemented cookies where the domain is set to the core domain with wildcard for subdomains. For example we may have two webapps one at appone.example.com and the other at apptwo.example.com. Both of which are looking at the same selection of cookies shared across subdomains by setting the cookie domain to .example.com.

Now this setup works great, we do not send our cookies with api requests and instead just send an authentication header so no issues with header size there and we do not have a need for these cookies to make there way into the request to cloudfront. However, these requests are instigated by the browser so the request can not be manipulated to remove the cookie header which is where the issues arise.

When we have quite a few cookies (around 30) two lots of cognito cookies and a few others containing information to instigate the cognito setup to utilise the cognito cookies. It means the request size falls around 22,000 bytes. This exceeds the limit aws of 20,480 bytes which is stated here. If my request is below 20,480 bytes it completes successfully.

Now considering I do not need these cookies to hit the cloudfront request I assumed you would be able to strip them from the header in part of the origin request policies or using Viewer request Lambda@Edge function. However, it does not seem to be getting far enough to hit this functionality.

Here is some example code provided by aws template. This Lambda@Edge function does not strip the headers as suggested above however should still log the event if being hit, if the request is less that 20,480 bytes it does. If not it does not log...:

exports.handler = async (event, context) => {
    console.log(event);
    /*
     * Generate HTTP response using 200 status code with a simple body.
     */
    const response = {
        status: '200',
        statusDescription: 'OK',
        headers: {
            vary: [{
                key: 'Vary',
                value: '*',
            }],
            'last-modified': [{
                key: 'Last-Modified',
                value: '2017-01-13',
            }],
        },
        body: 'Example body generated by Lambda@Edge function.',
    };

    return response;
};

Now, I think I could mitigate the issue by removing one set of the cognito cookies and the configuration cookies involved in instantiating that, however this is a less than ideal situation because it means that each time you chop and change between the two systems you will need to re-login which is not great and does not fit our use case which is quite specialised. The other solution is to remove the use of cookies and switch to local storage shared across domains. This however, then brings a security challenge with XSS and from initial research seems unviable and unacceptable.

So overall based on my current limited understanding on aws cloudfront my question becomes can the cookie header be stripped from the request and hence allow the request to be accepted without 494 error page. In our use case we only wish to use cookies as a means of cross domain storage so do not need thee cookies to venture up to the static js files request.

494 error image link

Answer 1

If you just want to avoid sending cookies with requests to static assets set up a different domain and serve them from there.

But I'm a really wondering what you're thinking here; If your angular app can access the token stored as a cookie then it isn't any safer than localstorage from an XSS standpoint.