Securing Tokens In A Progressive Web App
Security is at the top of the agenda for every technological development, especially so in the open world of the World Wide Web and Internet generally. The core underlying challenge is that the web and Internet were not designed with a modern level of security in mind. In terms of progressive web app development, this makes creating web experiences that are both highly usable and highly secure difficult. Appropriate progressive web app security can be achieved however, here are a few of our expert tips and methods to help you.
How to Secure Tokens In A Progressive Web App
Use OAuth And Distributed Identity Services
In recent years, technologies such as federated identity and OAuth ans Single Sign On have become very popular on the web. Instead of having one hundred different user names and passwords for one hundred different web portals, users can have one username and password provided by a trusted partner (e.g. Azure Active Directory) and use that to log in to all their web portals without having to disclose the password to those systems. This is accomplished using a system of secure “tokens” that authorise users to access different systems.
For illustration, let’s say we are building an Angular 7 Progressive Web App (PWA) that is authorised using OAuth against an Azure Active Directory. The Angular App accesses a web API that is hosted on an App Service in Microsoft Azure. APIs frequently request an OAuth token to be provided by the client (the PWA here) with every request. Learn more about integrating Auth0 with Azure Active Directory.
Do Not Use Web Storage
Use Secure HTTP Only Cookies
Take Care With CSRF / XSRF Tokens
Obviously, this gives rise to a cross-site scripting vulnerability with the CSRF token, which should be defended against using normal mitigations. A combination of good cross-site scripting hygiene, a secure HTTP only cookie for authentication and a CSRF token is a good combination for building a secure ecosystem for your PWA and web API.
Consider Indirect All API Calls
An excellent solution to the above quandary is to simplify web API access by constructing your PWA so that ALL web API calls are ONLY to the domain that hosts both the PWA and the web API. This means that you can take advantage of modern browsers and cookies’ “same site” capability, although this cannot be totally relied upon due to older browsers still being in use. It also means that you can perform some server-side programming to include the CSRF in the HTML served up for the client-side App rather than sending it around in cookies.
In this scenario, all access to third-party APIs will be managed by the PWA server-side component. This allows more secure web API credential storage methods to occur on the server-side rather than insecurely on the client-side. This is very useful when accessing a web API that requires the passing of an OAuth token in a header, for example.
Benefits of Securing Tokens In A Progressive Web App
Securing progressive web Apps is made more simple as the secure contexts (HTTPS), service worker(s) and manifest file features include added security measures to stop malicious users infiltrating your App. The security benefits of PWAs are explained below:
- Secure contexts (HTTPS)
A PWA must be served over a secure network to be entrusted by users, particularly where a monetary exchange is involved. PWAs are SSL encrypted by browsers, making them more secure than connections in traditional native Apps.
- Service workers
Service workers are a script run separately from your main browser that intercepts network requests, deals with caching and enables browser support. Essentially, they are a proxy between the front and backend of a web App. Service workers are only registered on HTTPS encrypted browsers so that they cannot be tampered with and have additional security features to limit the impact of malicious server workers, explained below:
- Service workers only have access to the Cache Storage and indexedDB for caching purposes but not the Local Web Storage or Session Storage.
- Service workers can’t read or set forbidden headers.
- Manifest file
The manifest file in a PWA sits in the HTML, and it is responsible for the display and appearance of your App, including name, background colour, icon, etc. When a manifest file is present, a malicious attacker cannot override the manifest and target the App. Therefore the name, description and icon of your PWA remain secure.
Additional Benefits of PWAs:
- Automatic updates
PWAs benefit from browser support and automatic maintenance and utilise these technologies to deliver an optimal web experience for users. Automatic updates and maintenance mean that a high level of security is maintained.
- Improved performance
PWAs take advantage of new technologies to make a more powerful web App without impinging on device storage or mobile battery life. The caching done by service workers enables PWAs to install and load faster, even when operating offline.
- Improved user experience
PWAs are designed to provide a good, secure user experience. Once installed, users can view the PWA icon on their home screen and access PWAs from their device as they would use a native App. Service workers can re-engage users using push notifications when they’re not actively using their browser. Plus, PWAs are network independent, utilising cache storage, meaning users can browse content or sites even when offline.
For a more detailed explanation of PWAs and their benefits, have a read of our blog. Or, if you wish to discuss securing progressive web Apps in more detail, please contact us to speak to one of our friendly specialists.