Third-Party Cookies Are Gone (Or Not). How Can I Still Embed Cross-Site Apps?

In 2024, there has been significant discussion about third-party cookies becoming obsolete or user configurable. While these changes are beneficial for user privacy, they complicate the lives of web application developers who want their applications or widgets to be shared across different websites. The main question remains: can I still make embedded web applications? How can we ensure that those still work?

Here’s a brief guide on how to configure your web application to ensure it remains unaffected by upcoming changes.

Server-Side Configuration

Assuming your web application is already designed for website embedding, you only need to configure a few things on the server side to keep your application up and running.

1. Enable TLS for HTTPS

While maintaining secure data transmission has been a best practice for a long time, enabling TLS (or SSL) for HTTPS is now mandatory. The method for enabling SSL depends on where your application is hosted. For instance, Fly.io offers a force_https = true option to configure apps to use HTTPS only.

2. Configure Session Cookies

Embedded applications often rely on session cookies to function correctly. Properly configuring these cookies with the necessary attributes is critical.

1. SameSite=None: Means that the browser sends the cookie with both cross-site and same-site requests. The Secure attribute must also be set when setting this value.
2. Secure: Ensures that the cookies are only sent over HTTPS, protecting them from being intercepted in transit.
3. Partitioned: This attribute, part of the CHIPS (or Cookies Having Independent Partitioned State) proposal, ensures that cookies are partitioned based on the top-level site context, adding an extra layer of privacy by isolating cookies to the specific context. This is important since otherwise browsers will block the cookies in the future.

In the end, your session cookie headers should look something like this:

Set-Cookie: PHPSESSID=abcde12345; path=/; HttpOnly; SameSite=Strict; Secure; Partitioned

or

Set-Cookie: JSESSIONID=abcde12345; Path=/; HttpOnly; SameSite=Strict; Secure; Partitioned

3. Add Basic CORS Headers

The W3C defines the CORS protocol, which allows you to specify which sites can embed your content. Adding the appropriate CORS headers to your HTTP responses ensures that your content can be securely embedded across different origins. Some required during the preflight (OPTIONS) request and others during the actual (GET, POST,...) request.

Sent During Preflight Requests:

• Access-Control-Allow-Methods: Specifies the HTTP methods (e.g., GET, POST, PUT, DELETE) allowed when accessing the resource. This header is sent in response to a preflight request to inform the client of the methods supported by the server.
• Access-Control-Allow-Headers: Lists the HTTP headers that can be used during the actual request. This is sent in the preflight response to let the client know which headers can be included in the actual request.
• Access-Control-Max-Age: Indicates how long the results of the preflight request can be cached by the client. This allows the client to cache the preflight response for a specified duration.

Sent During Actual Requests:

• Access-Control-Allow-Origin: Specifies the origin(s) allowed to access the resource. You need to use an explicit list of allowed domains instead of the wildcard (*). This header is sent in the actual response to indicate which origins have access to the resource.
• Access-Control-Allow-Credentials: true tells browsers that the server allows cross-origin HTTP requests to include credentials. This is sent either in preflight or in the actual response to indicate whether credentials (such as cookies or HTTP authentication) are allowed to be included in the real request.

How you set these headers in HTTP responses depends on the framework and runtime environment you use, but the principles are the same.

Configuring the Hosting Page

Some HTTP headers need to be configured on the hosting page. Consider setting up the Cross-Origin-Embedder-Policy and the Cross-Origin-Resource-Policy. By default, these policies allow embedding and resource loading, but configuring them helps enhance the security of your application by restricting unauthorized access and embedding.

Demo Setup: Seeing is Believing

As you might know, my default full stack consists of Spring Boot and Vaadin, and that is what I use here too. You'll find my small demo live at: samie.github.io/vaadin-cors-sample. When using Chrome, test it with the third-party cookies disabled.

Conclusion

Yes, embedding cross-site applications will remain a valid approach in the future. By carefully configuring your server to handle cookies and headers correctly, you can maintain secure and functional cross-origin embedding even as third-party cookies evolve. This ensures your applications or widgets can continue to work across different websites without compromising on security or functionality.

Like always, source code at GitHub. See you there!