HafezSecure

Mobile PWA Security Assessment

Security assessment for mobile Progressive Web Applications

Request ServiceContact Us
About This Service

Our Mobile PWA Security Assessment tests a Progressive Web App as people install and run it on a phone. It is a web app first, so we test it with the full OWASP Web Security Testing Guide, then add the surface a PWA introduces once it is installed to the home screen and runs offline: a service worker that sits between the page and the network, a Cache Storage and IndexedDB that keep data on the device, a web app manifest that controls how it installs and what it can reach, and the mobile permissions it requests — push, geolocation, camera, and the rest. On a phone the app runs in a standalone window, often on a shared or lost device, so data kept on that device and a service worker with too broad a reach both matter 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 on the device

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

Web app manifest review: start URL, scope, display mode, installability, and related applications

Mobile permissions the app requests — push, geolocation, camera, and notifications — and how they are used

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, the other security response headers, and third-party client-side scripts

How It Works

1
Scoping & Access
We agree the boundary and set the test depth: black-box from the outside, grey-box with a test account per role, or white-box with source access for the deepest coverage. We note the roles, the offline features and mobile permissions in use, and anything to avoid. Testing usually runs against a staging environment so production data stays untouched.
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 the app keeps offline in Cache Storage and IndexedDB and whether that data is sensitive — which matters more on a phone that is shared or lost.
4
Manifest, Permissions & Headers
We review the manifest and how the app installs and runs in a standalone window, the mobile permissions it requests and how it uses them, the secure-context and HTTPS enforcement, the Content Security Policy and other security headers, push and background sync, and any secrets 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 installed PWA
  • Manifest, mobile-permission, secure-context, and security-header review
  • CVSS severity and business impact for every finding
  • Prioritized remediation roadmap
  • Re-testing after remediation

Why HafezSecure

Web and Installed-App Depth
We test the whole application, not just the shiny features — the web app underneath is where most real risk lives, and the installed PWA layer on the phone 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, and the PWA surface is tested on top of it.
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 Mobile PWA Security Assessment?

It tests a Progressive Web App as it installs and runs on a phone, using the OWASP WSTG for the web application plus the surface a PWA adds — the service worker, offline storage, the manifest, mobile permissions, and push — with every finding proven and rated.

How is this different from your web PWA assessment?

The methodology is shared — a PWA is a web app either way. This assessment centers on how the app behaves once installed on a phone: the standalone window, the mobile permissions it requests, and data kept offline on a device that is easily shared or lost. If your PWA is used mainly in a desktop browser, the web PWA assessment is the closer fit.

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, offline 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 on the phone 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 phone, by whoever holds it. We check what is stored, whether it needs to be, and whether it is protected.

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?

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, and we give a firm estimate after scoping.

Related Services

Complementary services that might be useful for you

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