Does Angular's service worker verify cached API data it serves offline?

Answer to the Core Question

Angular’s ngsw does not perform an integrity check on responses stored in dataGroups when it serves them offline. The hash-based validation mechanism is applied exclusively to the assetGroups section, which covers static files listed in ngsw-config.json. For API responses, the service worker returns the cached body as-is until the entry becomes stale according to maxAge or maxSize.

What Happens with a 304 Not Modified

When the strategy is set to "freshness", the service worker (SW) attempts a network revalidation before serving cached data:

1. The client sends a conditional GET request (utilizing If-None-Match or If-Modified-Since headers).
2. If the server replies with 304 Not Modified, the SW treats this as a successful revalidation and retains the existing cached entry.
3. If the network is unreachable, the SW falls back to the cached entry, even if it is technically stale, provided it has not exceeded the configured age or size limits.

Implementing Custom Data Verification

Because the Angular service worker does not verify the body or custom headers of a cached API response, the application must implement its own validation if data integrity is critical. Accepted patterns include:

• Header Comparison: Using ETag or Last-Modified headers to detect staleness, or storing a checksum in a custom header (e.g., X-Checksum) that the Angular application compares against a locally computed hash of the response body.
• Payload Versioning: Including a version number or timestamp within the JSON response payload and verifying it against a known required version in the application logic.
• Client-Side Hashing: Running a lightweight checksum (such as SHA-256) on the cached response and rejecting it if the hash does not match the expected value.

Practical Verification (Angular 17+)

To verify this behavior in your environment, you can use the following scoped steps:

# 1. Build the PWA with a dataGroup configured in ngsw-config.json
ng build --configuration production

# 2. Use Chrome DevTools → Application → Service Workers
#    Confirm the dataGroup entry exists in the Cache Storage.

# 3. Simulate offline mode via the Network tab.
#    Observe that the request is fulfilled by the service worker without hash validation.

# 4. Configure backend to send ETag/Last-Modified headers.
#    Verify that a 304 response results in the SW continuing to use the cached entry.

Assumptions and Uncertainty

This behavior is consistent with Angular 16 and 17. While generally stable, specific behavior may vary if you have implemented a custom service worker script that overrides the default @angular/service-worker logic. If you are using a custom sw.js instead of the generated ngsw-worker.js, the caching and validation logic will depend entirely on your manual implementation.