PWA Security Assessment

Security assessment for Progressive Web Applications (PWA) including service workers and offline capabilities

About This Service

Our PWA Security Assessment tests a Progressive Web App with the full OWASP Web Security Testing Guide, then adds the surface that a PWA introduces on top of an ordinary web app: a service worker that sits between the page and the network, a Cache Storage and IndexedDB that keep data on the device for offline use, a web app manifest, and push and background sync. A PWA still has every risk a web app has — injection, broken authentication, broken access control, cross-site scripting — and these client-side features add a few more. We carry every finding through to a working proof, rate it with CVSS alongside its real impact, and write it up with a concrete fix.

What's Included

Full web application testing per the OWASP WSTG: authentication, session management, access control, input validation, injection, XSS, and CSRF

Service worker security: registration scope, the update mechanism, and how it intercepts and serves requests

Cache poisoning and sensitive or stale data served from Cache Storage

Offline data at rest in IndexedDB and local storage, and whether it should be there at all

Web app manifest review: start URL, scope, permissions, and related applications

Secure context and HTTPS enforcement, and mixed-content issues

Push notifications and background sync abuse

Client-side logic and secrets exposed in the JavaScript bundle

Content Security Policy and the other security response headers

Third-party scripts and client-side supply-chain risk

How It Works

1
Scoping & Access
We agree the boundary and success criteria and set the test depth: black-box from the outside, grey-box with test accounts for each role, or white-box with source access for the deepest coverage. We note the roles, the offline features in use, and anything to avoid.
2
Web Application Testing
We test the application the way the OWASP WSTG groups it — authentication and session, access control, input handling and injection, cross-site scripting, and business logic — because a PWA is a web app first, and most real findings live here.
3
Service Worker & Offline Testing
We examine the service worker: its scope and update path, how it caches and serves responses, and whether it can be made to serve poisoned or stale content. We check what data the app keeps offline in Cache Storage and IndexedDB and whether that data is sensitive.
4
Client Storage, Manifest & Headers
We review the manifest, the secure-context and HTTPS enforcement, the Content Security Policy and other security headers, push and background sync, and any secrets or sensitive logic exposed in the client bundle.
5
Validation, Reporting & Re-testing
Every finding is verified with a reproducible proof of concept, rated with CVSS and the real business impact, and written up with a prioritized remediation path. After you fix, we re-test to confirm the fixes hold.
Deliverables
  • Executive summary with a risk overview for decision-makers
  • Detailed technical report, each finding with a reproducible proof of concept
  • Web application findings mapped to the OWASP WSTG
  • Service worker and offline-storage findings specific to the PWA
  • Manifest, secure-context, and security-header review
  • CVSS severity and business impact for every finding
  • Prioritized remediation roadmap
  • Re-testing after remediation

Why HafezSecure

PWA and Web Depth
We test the whole application, not just the shiny features — the web app underneath is where most real risk lives, and the PWA layer is where the rest hides.
Service Worker & Offline Expertise
We understand how a service worker intercepts traffic and how offline storage keeps data on the device, so we find the risks a generic web scanner never looks for.
Standards-based Coverage
The web testing follows the OWASP WSTG, so coverage is explicit and checkable rather than ad hoc.
Actionable, Prioritized Findings
Clear guidance prioritized by risk, with a reproducible proof of concept and a concrete fix for every finding.

Frequently Asked Questions

What is a PWA Security Assessment?

It tests a Progressive Web App for security weaknesses using the OWASP WSTG for the web application, plus the extra surface a PWA adds — the service worker, offline storage, the manifest, push and background sync — with every finding proven and rated.

How is testing a PWA different from a normal web application test?

A PWA is a web app first, so it needs the full web test. On top of that, the service worker, offline caches, and device storage add risks a normal web test does not look at — poisoned caches, sensitive data kept offline, and a service worker with too broad a scope.

Which standards do you follow?

The OWASP Web Security Testing Guide for the web application, and current PWA security guidance for the service worker, storage, manifest, and secure-context features.

What access do you need, and do you offer white-box testing?

We can work black-box from the outside, grey-box with a test account per role, or white-box with source access. Grey-box is the usual choice; white-box with the source gives the deepest coverage of the client logic and the service worker. We agree the depth and scope before we begin.

What is the security risk of a service worker?

A service worker runs in the background and intercepts the app's network requests. If its scope is too broad, its update path is weak, or its caching is careless, it can serve stale or poisoned responses, keep sensitive data in a cache the user forgets about, or persist beyond a session. We test each of these paths.

Is data kept offline a risk?

It can be. Data stored in Cache Storage, IndexedDB, or local storage stays on the device and is readable by any script that runs in the origin — and, on a shared or lost device, by whoever holds it. We check what is stored, whether it needs to be, and whether it is protected.

Do you review the Content Security Policy and security headers?

Yes. A strong Content Security Policy is one of the best defenses against cross-site scripting, which is a leading web risk, so we review it and the other security response headers as part of every assessment.

How is the severity of findings decided?

Each finding gets a CVSS score for a common baseline, adjusted by the real impact in your application — what an attacker reaches, how easily, and what data or accounts are at risk. That is why two issues with the same CVSS can be prioritized differently.

Is re-testing after remediation included, and how long does it take?

Yes — after you remediate, we re-test the reported findings to confirm each fix holds. Duration depends on the size and complexity of the application; a typical assessment runs about one to three weeks, and we give a firm estimate after scoping.

Ready to Get Started?
Contact our team to discuss your security assessment needs