A scanner, a pentest report or a customer's security questionnaire asked whether the JavaScript you ship is readable, and you need an answer.
What an automated scanner actually checks
A scanner does not read your code the way a person does. It runs a fixed set of checks over whatever text it can pull out of the response: it matches secret-shaped patterns against your string literals, follows a sourceMappingURL comment back to your original source when one is there, fingerprints the versions of the libraries you bundled, and labels the file as plain text or minified.
None of that requires understanding your logic. A pattern match finds a key whether or not the surrounding code ever runs. A source map turns a scan into a full source read in one request. The person reading the report sees the label, and a plain or minified label tells them the source is right there.
What an obfuscated build changes in the report
Literals are encoded by default, so the text a secret-pattern check looks for is not in the file. strings.leaks.max fails the build when a readable literal survives, and names it with DIAG_SURVIVING_READABLE_LITERAL. A production build writes no .map file and no sourceMappingURL comment unless you ask for them with sourceMap.enabled and sourceMap.emitUrl, so there is no map to follow back to source.
A protection-level check still reports the file as obfuscated, which is what that check is for. The shape of the output is visible to anyone who looks at it; your logic and your strings are the parts that stop being readable.
A release build that answers the questionnaire
A release build that encodes its strings and keeps the map out of the output:
{
"preset": "hard",
"strings": {
"encode": true,
"leaks": { "max": 0 }
},
"sourceMap": { "enabled": false }
}sourceMap.enabled is already off in a production build. Setting it here makes the answer the same on every machine that runs the build.
Scan your own deployment first
Run the checks a scanner runs against your own deployment, before a customer does:
$ npx afterpack@latest audit https://your-site.example.comafterpack audit looks for exposed secrets and source maps first, then protection level, dangerous patterns, the detected stack, and known CVEs in what it can fingerprint. For a pipeline, add --diagnostics.format=json so the result can be parsed instead of scraped, and --diagnostics.level to choose how much detail comes back. Run it against every environment you deploy to, staging included.
Keep protectionMap.enabled on locally. The Protection Map traces anything the audit turns up back to the source region it came from.
What a clean scan does not mean
Auditing your own site tells you what any reader can already pull out of it, and a build with encoded literals and no shipped map carries far less readable text than the source it was built from.
Obfuscation does not fix what a scan found. A vulnerable dependency, an injection bug, or a credential that already went out is still live in the running application after the build, so fix those at the source and rotate the credential.
Next
- Audit: the command reference and how to read the results.
- Threat model: the boundary between a static reader and someone running your code.
- Diagnostics: every code a build or an audit can emit.