What is WebView and Compliance Concerns around WebView

Imagine an e-commerce company already has a complete website. Now, they want to expand to mobile with both Android and iOS apps. The problem is that they don’t have much time. Rebuilding every features on existing website to a native mobile app would be time-consuming, especially when the development team has limited mobile app experience.

To build native apps, their development team would have to maintain 2 additional codebases: 1 for Android, (typically written in Kotlin) and 1 for iOS (typically written in Swift). Each codebase would need to reproduce every features available on the website, while also adapting them to convention on each mobile phone. If the complete website took 3 years to develop, high chance is that native mobile apps would take the same amount of time.

So instead of building everything from scratch (native apps), they choose a simpler approach: put the existing web application inside a WebView and ship it as a mobile app.

1. What is WebView ?

1.1. A Web Browser Inside A Mobile App

As we already know, a website is composed of HTML, CSS, and JavaScript. Web browsers such as Chrome, Firefox, and Safari use browser engines to parse these code into the what users see on the screen.

WebView works in much the same way. It also provides a browser engine that can parse HTML, CSS, and JavaScript and rendering the result inside a mobile application. In other words, instead of opening a website in a standalone browser such as Chrome or Safari, the website can be displayed directly inside a mobile app.

The main difference between a normal web browser & WebView mobile app is how its browser engine navigates user:

• In a normal web browser: when a user wants to visit a website, they first open a browser such as Chrome and enter the website’s address into Chrome’s address bar. Chrome then load website’s HTML, CSS & Javascripts and uses its browser engine to parse them into what displayed on the screen.
• In a WebView-based mobile app: The process is slightly different. The user first downloads and opens the mobile app on their phone. The mobile app then reserves a UI space (usually fullscreen) for a WebView component once it started. When building the app, the developer had already defined the website’s URL in the application’s source code. Once the app starts, it instructs its embedded WebView to go to that predefined URL. The WebView then retrieves and renders the website inside the mobile app.

At first, this may sound almost exactly like using Chrome on Android or Safari on iOS to open a URL. And yes, fundamentally, it is. The key difference is that the user does not have to open a browser or manually enter the URL. The mobile app does it automatically behind the scenes, making the website appear as if it were a native mobile application.

1.2. A Low Cost Solution

1.2.1. Least Development Time

The biggest advantage of WebView is developers can reuse what they have already built on the website such as application’s business logic, user interface, and functionalities, etc. Instead of rebuilding all of features as native Android and iOS apps, developers can just place the existing web application inside a WebView. This can significantly reduce development time and cost.

1.2.2. Quicker Update

There is also a major maintenance advantage: When the web application is updated with new UI, new features or bug fixing, those changes also can become available to the mobile application without requiring developers to rebuild and release a new version. In native app, each changes on website require development team to do the same for Android and iOS version, which often cost more, in both time and money.

1.3. How to know an app is actually WebView ?

It is hard to tell if a mobile app is using WebView instead of is built natively. If the website is well designed, it can appear nicely on mobile app’s WebView and normal users wont be able to notice the difference.

But, because its WebView actually is an web browser, it usually depends much on Internet, just like Chrome, Firefox and Safari. Therefore, there is a simple quick test to know if an app is using WebView: Offline Test. You can try turning on AirPlane mode on your phone and then open an app, if it does not appear normally, high chance that because it is a WebView. For more details:

2. Compliance Concerns around WebView

Although WebView is an acceptable solution when teams have a tight deadline and resources, WebView introduces a few compliance risks if the application has payment feature – which is common in an e-commerce app. These risks mostly stem from how many hops that payment data is passed through from user’s mobile to their bank account.

2.1. Payment Data Concerns

Below diagram demonstrates what components sit between user’s mobile phone and their bank account when users use online purchase feature:

Mobile App (e.g. an online shopping app)
    │
    ▼
  WebView (a web browser inside a mobile app)
    │
    ▼
Web Checkout (Mobile App instructs WebView to go to a Checkout URL)
    │
    ├── JavaScript (code that build up the website & can read Payment Data)
    ├── Analytics (can see how users interact with website)
    ├── CDN (many websites put their Javascript in these 3rd-party systems and load Javascript from it)
    ├── Cookies (if be stolen, hackers can impersonate users)
    └── Payment Form (inputs where users enter their Card Number, CVV and OTP)
            │
            ▼
      Payment Processor (e.g. Online Banking, QR Payment, ...)

For an app has payment feature & using WebView, the main compliance concern is that the Payment Form is surrounded by many components that can potentially read user’s card info. This create privacy risks:

• JavaScript: This is the engine that functions today websites. Javascript code can read and modify any information in websites, including Checkout websites with user’s Card Number, CVV or even OTP when users entered to inputs. If, somehow, the Javascript code that built your Checkout website is altered by hackers, they can steal users’s Payment Data.
• Analytics: Many websites use 3rd-party Analytic services such as Google Analytic to understand how users interact with their websites. But because these services are 3rd-party, it means that user’s payment data can potentially be leaked to these services owners.
• CDN: Many websites host their Javascript code on CDN services for faster loading time. CDN services also 3rd-party services, so if hackers somehow can modify Javascript code hosted on a CDN, they can steal user’s payment data.
• Cookies: This is often targeted by hackers because if they can steal user’s Cookies of a website, they can impersonate users on that website. Cookies often store user’s login session ids those only are allocated after users logged in successfully.
• Payment Form: When users enter their card number, CVV or OTP to inputs, Javascript code can read these information. If Javascript code is already altered by hackers, they can steal user’s payment data.

Compared with a native app, the main difference is that there is less hops between user’s phone and Payment Processor. For a native app, above flow becomes:

Mobile App
    │
    ├── Native UI
    │
    └── Payment SDK
            │
            ▼
      Payment Processor

• Native UI: Different from WebView, native mobile app UI is not rendered by Javascript and use no 3rd-party service to serve Javascript like on WebView. Code that render UI locates right in user’s phone but it does not automatically eliminate all of compliance risks if Native UI uses 3rd-party libraries.
• Payment SDK: Payment companies often provide Software Development Kits (SDKs) that allow developers to integrate payment functionality into mobile apps without having to understand or implement the underlying complexities of payment processing. This reduces the amount of custom payment-related code developers need to write and, consequently, the risk of accidentally exposing sensitive card data through implementation errors.

Native apps generally provide greater control over the payment environment, while WebView apps trade that control for development speed. For an e-commerce company handling card payments, this trade-off can have compliance consequences. A WebView introduces additional components such as JavaScript, Cookies, 3rd-party services, those must be secured as well.

These concerns are addressed by PCI DSS (Payment Card Industry Data Security Standard), which requires organizations that handle payment card data to protect the payment environment and prevent sensitive cardholder data from being exposed, modified, or improperly accessed. For an e-commerce app using WebView, this includes controlling JavaScript and third-party scripts, protecting payment forms and session cookies, ensuring the integrity of payment pages, and monitoring for unauthorized changes in how the app works.

If your app fails to protect cardholder data, it may be considered non-compliant with PCI DSS (Payment Card Industry Data Security Standard). The company may then face additional security requirements, financial penalties from payment providers or card brands, higher processing fees, or even the loss of its ability to accept card payments. The exact consequences depend on the severity of the violation and the company’s agreements with its payment providers.

2.2. Personal Data Concerns

If your WebView application does not have payment feature, there are still other concerns about Personal Data, addressed by GDPR (General Data Protection Regulation).

GDPR is a European Union regulation that governs the collection, processing, storage, and sharing of personal data. For a WebView-based mobile app, GDPR compliance can become a concern because the same reason like above when JavaScript, cookies, analytics tools, advertising services, or third-party SDKs can collect user information such as names, email addresses, IP addresses, device identifiers, or browsing activity. Your apps must ensure that this data is collected and processed lawfully, securely, and transparently, and that users’ GDPR rights are properly supported.

An app does not automatically violate GDPR simply because its app collects personal data. A Data Protection Authority (DPA) can investigate when they receive user complaints, discovering a potential violation, or obtaining information from another authority. The DPA can request information, audit the company’s data-processing activities, and examine how personal data is collected, stored, shared, and protected. If the investigation finds that the company violated GDPR—for example, by processing data without a valid legal basis, failing to protect personal data, or violating users’ rights—the authority can issue a warning, reprimand, order the company to change or stop its processing activities, or impose a fine. For serious violations, the fine can reach €20 million or 4% of the company’s total worldwide annual turnover from the preceding financial year, whichever is higher. The actual fine depends on factors such as the seriousness and duration of the violation, the number of people affected, whether the violation was intentional or negligent, the damage caused, and the company’s efforts to mitigate the problem.

2.3. Health Data Concerns

Imagine that there is a hospital in USA now publishes their own mobile apps for patients to check their health data. This mobile app uses WebView as a Low Cost Solution. Beside PCI DSS, GDPR, now this hospital app has another concerns addressed by HIPPA (Health Insurance Portability and Accountability Act).

HIPPA is a U.S. federal law that sets rules for protecting people’s health information. In simple terms, HIPAA requires healthcare organizations and their business associates to properly protect Protected Health Information (PHI), such as:

• Patient names and contact information
• Medical records and diagnoses
• Prescription information
• Health insurance information
• Billing and treatment information

For this WebView example, the important point is that HIPAA can become relevant if a healthcare app uses WebView to handle or display PHI. Third-party JavaScript, analytics, cookies, or other services embedded in the WebView could potentially expose that information if they are not properly vetted.

If this hospital fails to protect Protected Health Information, the U.S. Department of Health and Human Services (HHS), through its Office for Civil Rights (OCR), can investigate the potential HIPAA violation. An investigation may start from a patient complaint, a reported data breach, or an OCR compliance review. OCR can request documents and other evidence to determine whether the organization followed HIPAA’s Privacy, Security, and Breach Notification Rules. If a violation is confirmed, OCR may require corrective action or a settlement, and in more serious cases, impose civil monetary penalties.

3. How to mitigate Compliance Risks for WebView mobile app

If you want your WebView app to reduce the risk of violating PCI DSS, GDPR, HIPAA, and similar regulations, use Data-First Approach:

1. Know what data you collect: Identify payment data, personal data, health data, cookies, analytics data, credentials, etc.
2. Minimize data collection: Do not collect or store data that your app does not actually need.
3. Vet JavaScript: Only load trusted scripts and avoid allowing third-party JavaScript to access sensitive forms or information.
4. Vet third parties: Check analytics, advertising, CDN, payment SDKs, and other libraries to understand what data they can access and where they send it.
5. Encrypt/Hide sensitive data: Encrypt data in transit and at rest, avoid putting sensitive information in logs, URLs, cookies, or local storage, and use secure authentication mechanisms.
6. Separate sensitive functions: For payments or highly sensitive information, consider using a trusted native payment SDK or hosted payment solution rather than handling raw data directly inside a WebView.
7. Obtain proper consent: Where required, obtain user consent before collecting or sharing personal data, particularly for analytics, advertising, and tracking.
8. Have a privacy policy: Clearly explain what data is collected, why it is collected, who receives it, and how long it is retained.
9. Monitor and test: Regularly test the app, WebView, APIs, third-party scripts, and dependencies for vulnerabilities and unauthorized data exposure.
10. Prepare for incidents: Maintain procedures for detecting, investigating, and reporting data breaches when required by applicable regulations.

Do not assume that using a payment provider, WebView, or third-party SDK automatically makes the app compliant. You need to understand the complete data flow and verify that each component handles sensitive information appropriately.