Using Clear-Site-Data to Wipe Storage via JavaScript

The Clear-Site-Data HTTP response header provides a secure, server-driven mechanism to clear browsing data associated with a web application’s origin. By returning this header in response to asynchronous JavaScript requests—such as a fetch() or XMLHttpRequest sent to a logout or session termination endpoint—web developers can instantly instruct the client’s browser to purge cookies, local storage, indexed databases, cache, and active execution contexts without requiring manual client-side cleanup scripts.

How Clear-Site-Data Works

When a browser makes a network request to an origin, the server can include the Clear-Site-Data header in its HTTP response. The browser inspects this header and immediately clears the specified types of data associated with that specific origin.

Because the header operates at the browser engine level, it can delete data that JavaScript cannot typically reach or safely clear, such as HttpOnly cookies, service worker registrations, and network caches.

Supported Directives

The Clear-Site-Data header accepts one or more quoted string directives:

• "cache": Clears browser caches, including the HTTP network cache, pre-fetched resources, and memory cache.
• "cookies": Removes all cookies associated with the response’s origin, including HttpOnly and Secure cookies.
• "storage": Wipes all web storage mechanisms, including localStorage, sessionStorage, IndexedDB, WebSQL, Cache Storage (Service Worker caches), and unregisters active Service Workers.
• "executionContexts": Destroys current browsing contexts (reloads the page or closes associated tabs/frames) to prevent memory-held state from persisting.
• "*": Wildcard that clears all supported data types.

Triggering Wipes via JavaScript Endpoints

To trigger a wipe using client-side JavaScript, the frontend application makes an asynchronous request to a dedicated backend endpoint.

1. The Frontend Request

A client-side script executes a request, typically during an event like user logout or account switching:

async function handleLogout() {
  try {
    const response = await fetch('/api/logout', {
      method: 'POST',
      credentials: 'same-origin'
    });

    if (response.ok) {
      // Redirect to login page after storage is cleared
      window.location.href = '/login';
    }
  } catch (error) {
    console.error('Logout failed:', error);
  }
}

2. The Backend Response

The server processes the request, invalidates the server-side session, and attaches the Clear-Site-Data header to the HTTP response:

HTTP/1.1 200 OK
Content-Type: application/json
Clear-Site-Data: "cache", "cookies", "storage"

{"message": "Logged out successfully"}

Alternatively, to wipe everything:

Clear-Site-Data: "*"

3. Client Execution

Upon receiving the response containing the header:

1. Interception: The browser processes the Clear-Site-Data directives before completing the promise for the fetch() call.
2. Purge Execution:
   • The origin’s localStorage and sessionStorage are cleared.
   • IndexedDB instances are closed and deleted.
   • Registered Service Workers are unregistered and their associated Cache API stores are deleted.
   • Scoped cookies are invalidated and deleted.
3. Completion: Control returns to the JavaScript fetch resolution, allowing the frontend script to handle redirects or UI updates with a clean state.

Key Considerations and Constraints

• HTTPS Requirement: The Clear-Site-Data header is ignored over insecure HTTP connections (except for localhost).
• Origin Scoping: The wipe is strictly bound to the origin (protocol, host, and port) of the URL serving the header. Subdomains must return the header separately if their storage also needs to be cleared.
• Execution Context Limitations: Using "executionContexts" or "*" will cause the current page to reload or terminate, which may interrupt any remaining JavaScript execution following the fetch() call.