OWASP MASVS · Resilience · Hybrid Apps

The one standard on this site that asks for this by name.

Ten regulatory regimes are documented here — payment cards, health data, the Cyber Resilience Act, DORA, the GDPR, federal contracting, accessibility, the AI Act, medical devices, NIS2 — and not one of them mentions obfuscation. The OWASP Mobile Application Security Verification Standard does, because it was written for a threat model where the attacker is holding the device. That makes this page the inverse of every other compliance page here, and the honest part is what the standard asks for that a JavaScript protector cannot provide.

Hybrid App Guide Evidence Packet
The Short Version

It asks · It asks for more than this · It ranks it last

Three findings carry the practical weight, and the third one is the one teams get wrong.

Resilience is a named categoryUnlike every regulation covered here, this document expects reverse engineering to be impeded.
Half of it is native, not JavaScriptRoot detection, attestation and pinning live below the bundle and stay there.
The standard calls it additiveIt does not substitute for storage, cryptography, authentication or network requirements.
Why This Page Exists

Every other compliance page here says the same thing. This one says the opposite.

The compliance pages on this site share a structure, because the regulations do. A regime describes outcomes — manage risk proportionately, handle vulnerabilities, keep records, disclose what your system does — and leaves technique to you. So the honest answer is always that protecting your JavaScript neither satisfies nor violates anything, and the useful conversation is about the places where a build pipeline changes how well you can meet a duty you already had. The OWASP Mobile Application Security Verification Standard breaks that pattern. It contains a category whose whole subject is making an application harder to take apart, and teams arrive here holding it as proof that they need this product. They half do, and the half they do not is the part worth reading.

Why this standard is different

It assumes the adversary owns the hardware. A regulation about an organisation asks how you manage risk; a verification standard for applications distributed to unknown devices has to assume the artifact will be unpacked, instrumented and modified, because that is the ordinary condition of a published mobile application.

What it is, structurally

A set of security categories with verifiable expectations, published by OWASP alongside a testing guide that describes how to check them. Teams use it as a self-assessment framework, as a specification for a penetration test, and as the vocabulary a customer questionnaire borrows.

Where it touches this product

Only through JavaScript. If your application ships a bundle inside a native shell, that bundle is a first class target for an assessor and a first class input for a protector. If your application has no JavaScript in it, this standard still applies to you and this product does not.

Scope

A mobile standard reaches a JavaScript codebase through exactly four shapes

Before mapping any expectation onto any option, establish whether the standard reaches your code at all. It reaches JavaScript through the packaging model, not through the language, and the four shapes below behave differently enough that the right answer for one is the wrong answer for another. Each has a dedicated guide on this site.

Hybrid: the whole application is web content

A Cordova or Ionic application ships your HTML, CSS and JavaScript inside a container and renders it in a web view. Practically all of your application logic is in files an assessor can extract from the package and read in a text editor. This is the shape where a protector has the most to do, and the hybrid guide covers the packaging specifics.

JavaScript driven native: the bundle behind the UI

A React Native application renders native components but the program driving them is a JavaScript bundle, shipped in the package or delivered as an update. The React Native guide covers the bundle and the bytecode engine question, and the over the air article covers the update channel, which assessors ask about more often than teams expect.

Native with an embedded web view

A native application with one or more web views for a checkout flow, a help centre, an onboarding sequence or a licensed third-party feature. The JavaScript inside those views is in scope for the same reasons, and the bridge between web content and native capability is one of the first things a tester probes.

Embedded and kiosk devices

Not phones, but the same threat model and often the same assessment vocabulary: the device is in the field, physically reachable, and the operator is not you. The embedded device guide covers this shape, including the runtime locks that behave differently when there is no ordinary hostname to read.

Fully native: out of scope for this product

A Kotlin or Swift application with no web content and no JavaScript bridge contains nothing this product can transform. Say so plainly in your assessment rather than buying a tool that has no input. A native code hardening product is the right category, and the same reasoning appears on the .NET guide for compiled assemblies.

The bridge, in every shape above

Wherever web content can call native capability, the definition of that bridge is in JavaScript and is therefore readable. Protecting it raises the cost of mapping it; it does not change what the bridge permits. Authorisation on the native side of the bridge is the control, and no build setting substitutes for it.

The Honest Mapping

What the resilience expectations ask for, and what this engine actually does

The resilience category has a recognisable internal structure: impede comprehension of the code, impede observation of the running program, detect modification of the application, and bind the artifact to an identity. Rather than quote control identifiers that change between revisions of the document — check the current published version for exact wording and numbering before you cite anything in an assessment — here is each theme against what this product provides.

Impede comprehension: fully answered

This is the core of the product. Identifier renaming removes the names that carry meaning, string handling removes the literals that let a reader navigate, control flow flattening destroys the shape of the original functions, and virtualised bytecode replaces selected functions with a program for an interpreter that ships with the output. The bytecode page covers the strongest option and its costs.

Impede instrumentation: partly answered

The anti monkey patching guard watches a defined list of platform functions — the function constructor and its string conversion, JSON handling, common array and object methods, timers, fetch, the XML request object, web sockets, event registration, the beacon, storage access and the web crypto digest — and re-checks them on a five second heartbeat. It also reads a pristine copy of each from a fresh realm, which lets it notice patching that happened before it loaded.

Detect tampering: partly answered

Self integrity checks and the environment integrity option cover modification of the shipped JavaScript itself. What they do not cover is modification of the package around it, because a checksum computed by code inside the artifact is computed by code the modifier already controls. Package signature verification is a platform service and belongs in the native layer.

Bind the artifact: fully answered

The watermark carries an authenticated tag in the output, the manifest records a source hash and an output hash per file, and a fixed seed makes the build reproducible so a claim about a past release can be checked rather than asserted. Reproducible builds and the proof pack cover the mechanics.

Device integrity: not answered

Root and jailbreak detection, emulator detection, hardware backed attestation and process level debugger detection are native platform capabilities. A JavaScript program running inside a web view that the operating system already started cannot establish them, and an assessor will not accept a bundle transformation in their place. Implement them natively.

Network integrity: not answered

Certificate pinning is a property of the network stack, and in a hybrid application that stack usually belongs to the shell rather than to your JavaScript. Protecting the code that makes a request does not change which certificates the request will accept. This is a separate category of the standard and it is assessed separately.

The Common Misreading

The standard ranks this category last on purpose

The most expensive mistake teams make with this document is reading the resilience section first. It is presented as an additional layer for applications whose threat model includes an adversary in possession of the device — not as a way to compensate for anything in the categories that come before it. An assessment that fails does so overwhelmingly in those earlier categories, and none of them is improved by transforming a file.

A credential in the bundle is a storage finding

Not a resilience finding, and obfuscating the file does not close it. The literal is recoverable at run time by anyone who inspects the running program, because your code has to use it. This is the single most common thing teams hope protection will fix and the clearest thing it does not; the detailed article explains why.

A client-side authorisation check is an authentication finding

If your application decides in the browser or the web view what a user is entitled to, that decision is editable by the user, protected or not. Moving the decision to your server is the fix. A protected build makes the check take longer to locate and does not make it authoritative.

Data left in web storage is a storage finding

The web view has ordinary storage, and its contents are readable on a device the analyst controls. Protecting the code that writes it changes nothing about what is written. The storage article covers this specifically.

Being additive is a feature, not a caveat

Read positively, this is the argument for doing the work in order. Satisfy the categories that describe how the application handles secrets, identity, data and transport. Then add resilience for the codebase that remains, which by that point is the part that genuinely encodes what your product knows how to do.

Practical Sequencing

Three build details that decide whether any of this survives packaging

A hybrid pipeline has more steps after the protection step than a web pipeline does, and each of them can undo the work. These are the three that come up repeatedly in support conversations, and all three are cheap to get right if you decide them before the first assessment rather than during it.

Protect after bundling, before packaging

Run the protection step on the emitted bundle, then let the container tooling package the result. Protecting individual source files and then bundling gives the bundler an opportunity to re-process output that was never meant to be read again, and it is the usual cause of a build that works in the browser and fails in the shell.

Everything that reads code runs first

Composition analysis, secret scanning, licence checking and static analysis all work by reading source, and all of them go quiet against protected output without reporting that they have. Run them against the pre-protection artifact. The inventory article covers the general rule, which applies to every regime on this site.

Keep the map, or lose your own crash reports

A stack trace from a protected build is unreadable to your own responders too, and mobile crash reporting is often the only signal you get from a device you will never see. Retain the identifier map for every release and rehearse reading a real trace; symbolication describes the workflow.

Frequently Asked

OWASP MASVS and protected JavaScript, answered

Is OWASP MASVS really the only standard that asks for obfuscation?

It is the only widely used one covered on this site that asks for resilience against reverse engineering as a named expectation rather than leaving it to be inferred. Ten regulatory regimes documented here, from payment card rules to the medical device lifecycle standard, describe outcomes and processes and never name the technique. The mobile standard is different because it was written for a threat model in which the attacker holds the device and can take the application apart at leisure. That is the situation in which impeding analysis becomes a stated goal instead of an optional habit.

Does a mobile standard apply to a codebase written in JavaScript?

It applies to the application you publish, whatever it happens to be written in. If you ship a hybrid application, a framework that packages a JavaScript bundle, or a native application with an embedded web view, then a substantial part of what an assessor will pull apart is JavaScript, and that is the part a JavaScript protector reaches. If your application is fully native with no web content and no bridge, then the standard still applies to you and this product does not, because there is no JavaScript in the artifact to transform.

Which resilience expectations does a JavaScript protector genuinely answer?

Three of them, in substance. Making the shipped code costly to read and follow, which is what renaming, string handling, control flow flattening and virtualised bytecode are for. Detecting that the running program has been instrumented, which the anti monkey patching guard addresses by watching a defined list of platform functions and comparing them against a pristine copy. And binding a build to an identity, which the watermark and the build manifest provide. Those are real answers to real expectations, and they are also only part of the category.

Which resilience expectations does it not answer at all?

Everything that lives below the JavaScript layer, and the list is worth being blunt about. Root and jailbreak detection. Emulator and debugger detection at the process level. Hardware backed device attestation. Certificate pinning in the network stack. Verification that the installed package signature matches yours. None of those can be implemented by transforming a bundle, because a bundle runs inside a runtime that has already been started by code you did not write. They belong to the native shell, and an assessment that expects them will expect them there.

How much weight does the standard itself put on this category?

Less than the teams who arrive here quoting it usually assume, and the document says so plainly. Resilience is presented as an additional layer for applications whose threat model includes an adversary with the device in hand, not as a substitute for the categories that cover storage, cryptography, authentication, network communication and platform interaction. An application that hardcodes a credential and then obfuscates the file has failed a different category and has not passed this one. Reading the resilience section first, and the rest afterwards, is the single most common way to misread the standard.

What does an assessor ask for beyond the protected file itself?

Evidence that the protected file is the one you meant to ship, and that you can account for it later. Three artifacts do most of that work here. The protection manifest records a source hash and an output hash for every file in the run. A fixed seed makes the build reproducible, so the same input and options produce byte identical output and a claim about a past release can actually be checked. And the watermark, an authenticated tag carried in the output, ties an artifact to a build rather than leaving you to argue from memory. Have those before the conversation rather than after it.

How much does protection change what a determined analyst can do on a device they own?

It changes the cost and the timeline, not the ceiling. On a device under the analyst's control, the runtime executes your code because it has to, and everything the program does is observable while it does it. What transformation buys is that reading the artifact stops being the cheap first step, that automated pattern matching over your source stops working, and that findings from one build stop transferring cleanly to the next when the output is regenerated. That is a genuine and measurable increase in effort, and it is the honest claim to put in an assessment rather than a claim about what is achievable in principle.

What is the shortest sensible plan for a hybrid team facing this standard?

Five steps. Read the whole standard before the resilience section, because most findings land elsewhere. Move every decision that carries authority or money to your server, so the categories about authentication and network integrity are satisfied by design. Protect the JavaScript that genuinely encodes your work, and confirm the packaging step does not undo it. Implement the native layer controls in the native layer, where they belong. Then keep the manifest, the seed and the watermark for every release, because the part of an assessment that goes badly is usually the part where nobody can prove what shipped.

Related Guides

Other compliance and evidence guides

PCI DSS and your JavaScript

The payment card regime, and the clearest example of a standard that names inventory and change detection but never names this technique.

Runtime defense options

The guards that run inside the protected program, what each one actually detects, and the failure actions available when one trips.

FIPS 140-3 and Common Criteria

The contrast case: a framework that names obfuscation as resilience, next to one that validates cryptographic modules.

Next Step

Check three things before your next assessment

Extract your own published package and read what comes out of it, because that is the assessor's first move and it is often the first time a team sees how much of their application is sitting there in plain text. Confirm your composition and secret scans run against the pre-protection artifact rather than the shipped bundle. Then take a real crash report from a device you do not own and try to read it with the map you kept — if that rehearsal fails, it will fail during an incident instead.

Open the Online Tool Ask a Question