Security and trust

Review source handling before you protect code.

Use this page for security, engineering, and procurement review. It explains hosted protection and local preflight boundaries, release validation, and where obfuscation fits in a broader security stack.

Security Processing Docs Security Evidence Validation Guide
What This Covers

Practical diligence for engineers, leads, and procurement reviewers.

Source handlingProtection sends selected JavaScript to the hosted service; local preflight does not.
Release validationUse settings review, smoke tests, exclusions, and protected-build checks.
Layered scopeHow obfuscation fits alongside monitoring and server-side authority.
A combination safe dial, representing source handling and release review for JavaScript protection
What a security review actually checks Source-handling boundaries, release validation, and workflow-to-policy fit are documented in advance so your team can review without starting with a sales call.
Buyer Evidence Map

Send reviewers to the proof path that matches the question.

Security & Trust explains the operating model. The Security Evidence hub turns that model into reviewable artifacts for runtime monitoring, checkout evidence, VM proof, and local source handling. Assessing a payment page? See PCI DSS v4 requirements 6.4.3 and 11.6.1. Placing software on the EU market? See the Cyber Resilience Act and your JavaScript. Serving EU financial entities? See DORA and your JavaScript front end. Handling personal data in the browser? See GDPR and your JavaScript front end. Selling into US federal or defense programmes? See FedRAMP, CMMC and your JavaScript build. Shipping an AI feature in the browser? See the EU AI Act and your JavaScript front end. Building software that is or supports a medical device? See medical device software and your JavaScript front end. Operating an essential or important service in the EU? See NIS2 and the JavaScript you ship.

Open Security Evidence Compare Fit
  • Runtime review: Dashboard Monitoring rows, status workflow, filtered CSV/JSON, and per-incident Evidence JSON. Runtime Defense docs
  • Checkout review: approved script inventory, header snapshots, runtime incident export, PCI DSS report, and QSA handoff boundary. Payment-page evidence
  • Advanced protection review: sample-only VM proof demo plus Corporate/Enterprise proof-pack fields for selected sensitive functions. VM proof demo
  • Source-handling review: hosted API, npm, desktop/local workflow, credential handling, generated artifacts, and support boundaries. Source handling docs
Source Handling

Pick the workflow that matches your code-handling policy

The right answer depends on where source is allowed to go. The online tool, the API, hosted desktop mode, and default npm protection send selected JavaScript to the hosted service. WinUI Local Standard, paid WinUI Local Advanced, and the npm CLI run with --local protect on your own machine after a source-free plan check. Desktop is the visual path for larger folders and mixed-file review.

Online tool

Best for quick evaluation, smaller scripts, and option reviews. Use it when a browser workflow is acceptable and you want immediate output.

Advanced team integrations

Best for repeatable releases that already have a build owner. Keep hosted credentials in environment variables or release-tool secrets instead of committed config.

Desktop and local review

Best when you protect embedded JavaScript in mixed files, manage larger folders, or need a visual project workflow. Selected JavaScript is sent to the hosted protection service.

Evaluation Question Practical Answer
Can we validate a release before sending source? Yes. Release owners can review settings, file paths, usage estimates, and release structure before protection.
Can we standardize settings across contributors? Yes. Reuse a desktop project or shared preset so each release starts from the same reviewed baseline.
Can we keep sensitive projects local? Current protection workflows send selected JavaScript to the hosted service. Local preflight commands do not upload source. In desktop mixed-file projects, surrounding non-JavaScript content stays local.
Can we test protected output separately? Yes. Protect into a separate release folder, then run smoke tests, browser checks, and monitoring review against that protected build.
Release Assurance

Make protection a reviewed release step, not an opaque black box

Operational clarity is what makes a release reviewable. Teams can document settings, validate output before release, preserve public names intentionally, and keep review notes with the protected files they ship.

Preflight checks

Review settings before protection so missing credentials, bad paths, or option drift fail early.

Compatibility rules

Protect generated JavaScript after bundling, preserve public names, and skip vendor or runtime files that do not need obfuscation.

Release metadata

Use protected-output folders and release notes when operations teams need a reproducible release record.

Local fallback

Move the release into the desktop app when mixed content, embedded scripts, or visual review matters more than automation speed.

Framework Coverage

Use one protection pattern across modern JavaScript delivery stacks

Review teams often want to know whether protection guidance stops at a browser text box. It does not. The documented workflow is to build first, then protect the emitted JavaScript with the release path that fits the project.

Vite, Webpack, Rollup, esbuild

Protect generated chunks after bundling so bundlers stay responsible for code splitting, tree-shaking, and framework compilation.

React, Vue, Angular, TypeScript

Protect the JavaScript they emit, then preserve public symbols, hydration hooks, and SDK-facing entry points with deliberate exclusions.

Advanced team automation

Use release-tool secrets, shared settings, and protected-build smoke tests when protected output becomes part of a standard deployment process.

Mixed-file desktop path

Move into the desktop app when a release includes HTML, PHP, ASP, ASPX, JSP, or embedded script blocks that need a local review path.

Framework Integration Guide Ways To Use It Protected-Build Validation
Company Context

An established product with a documented history

When buyers ask whether JavaScript Obfuscator is an established product, the answers are public: a long-running release history, a named company behind the product, and a documented client base.

Two decades of releases

JavaScript Obfuscator has been shipped under the same product line since 2004, with a focus on practical code protection that has tracked changes in JavaScript itself.

Named company

RichScripts Inc. publishes its address, support contact, terms of service, privacy policy, and the local-versus-hosted workflow expectations used during evaluation.

Documented client base

The clients page documents the breadth of teams that have shipped with JavaScript Obfuscator over the years — useful context for buyers running their own evaluation.

About The Company Historical Client Context Contact The Team
Compliance Context

How the workflow maps to the frameworks procurement teams reference

JavaScript Obfuscator is a code-protection tool, not a compliance certification. What we can document is how source handling and release review work, so legal, security, and procurement teams can connect our processing model to their existing program without a sales call.

GDPR / CCPA — data minimisation

Submitted JavaScript is processed for the duration of the request. Large transport payloads may use temporary server storage; those files are size-limited and removed when the request ends. The online tool, hosted desktop mode, and default CLI protection send selected JavaScript to the hosted service; WinUI Local Standard, Local Advanced, and the npm CLI run with --local do not submit source at all. Review this data flow against your organisation’s GDPR and CCPA requirements.

OWASP Top 10:2025 — A03 software supply chain

The 2025 list elevates software-supply-chain failures to A03. The supply-chain integrity tools map directly: HMAC watermarks prove which build produced a file, Ed25519-signed release manifests detect post-signing tampering, the third-party-script inventory flags unknown or swapped scripts on payment pages, and AI script governance watches for data leaving to LLM endpoints. Obfuscation remains a layer, paired with server-side authority.

PCI DSS v4 — req 6.4.3 & 11.6.1

For payment-page scripts, the jso-protector compliance pci-dss-v4 reporter generates an evidence report mapping your signed build to req 6.4.3 (script authorization + integrity + inventory) and 11.6.1 (tamper detection + alerting). It consumes your own manifest, so the evidence reflects the build you actually shipped — not a generic vendor statement. See the payment-page protection guide.

HIPAA — PHI-adjacent web apps

For health-information apps where JavaScript touches sensitive workflows, hosted protection sends the selected JavaScript to the service — confirm that data flow is permitted before submitting regulated or sensitive source. Where source must stay on the build machine, WinUI Local Standard and paid Local Advanced (and the npm CLI's --local) protect the source body on-device after a source-free entitlement check. The browser-side safeguards, the tracking-technology question, and the full mapping are in HIPAA and JavaScript.

NIST SSDF (SP 800-218)

Make protection a deliberate, reviewable release step. Ed25519-signed release manifests give the build-provenance evidence SSDF practices PS.3 and PW.6 ask for: a verifiable record of which protected files shipped from which build, checkable in CI with --verify-release.

Audit notes for reviewers

We do not currently hold an independent SOC 2 or ISO 27001 attestation. What is published instead: source-handling behaviour, release-validation expectations, and support and contact channels. Current protection workflows send selected JavaScript to the hosted service and do not fit projects that require code to stay on a workstation throughout. Buyers running a formal review can request the same in writing.

Generate your own evidence, per build

Most vendor compliance material is a static PDF describing the vendor’s program. JavaScript Obfuscator’s evidence is generated from your build artefacts, so it reflects what you actually shipped. Run it in CI:

# PCI DSS v4 evidence (req 6.4.3 + 11.6.1) from your signed manifest
npx jso-protector compliance pci-dss-v4 \
  --manifest dist/build.manifest.json.sig \
  --root dist --watermark-key "$JSO_WATERMARK_KEY" \
  --beacon-url "$JSO_BEACON" --siem splunk-hec \
  --output reports/pci-dss-v4.md

# Build-provenance check (NIST SSDF PS.3 / PW.6)
npx jso-protector --verify-release dist/build.manifest.json.sig --verify-root dist

The PCI report exits non-zero on evidence gaps, so it doubles as a CI gate. Output is Markdown + JSON for your auditor or GRC system. This is documentation of how JavaScript Obfuscator helps you meet controls — it is not a third-party certification of JavaScript Obfuscator itself.

Security & Processing Doc Release Workflow Doc Procurement Questions
Where JavaScript Obfuscator Fits

Code hardening with published pricing and full workflow coverage

  • Online tool, desktop app, and optional advanced release paths.
  • Protection for generated bundles and embedded JavaScript in mixed files.
  • Cross-file controls, exclusions, domain/date locking, compression, and batch processing.
  • Public documentation for workflows, compatibility validation, and source handling.
Where Server Authority Still Belongs

Pair obfuscation with the right server-side controls

  • Keep secrets and final authorization logic on the server, not in shipped JavaScript.
  • For live alerting and anti-tamper telemetry, pair JavaScript Obfuscator with a runtime security monitoring platform.
  • Keep licensing, payments, and account authority on the server whenever possible.
  • Review high-risk browser logic separately when active attackers are expected.
Team Operating Model

What teams can standardize today, even without a heavier enterprise platform

JavaScript Obfuscator now includes RBAC, scoped tokens, tamper-evident release audit contracts, OIDC/SAML configuration validation, and a SCIM 2.0 organization-user lifecycle core. Production hosting must still connect those contracts to durable tenant storage and server sessions; SOC 2 and managed analyst operations are not claimed. Review the governance boundary.

Reviewed shared baseline

Keep one desktop project, exported JSON preset, or jso.config.json file as the reviewed baseline so releases start from the same option set.

Credential discipline

Store hosted credentials in release-tool secrets or environment variables, keep Web.config out of update archives, and use the deployment hygiene checklist before release handoff.

Release evidence

Use compatibility checks, release notes, protected-output folders, and smoke tests as evidence when engineering or procurement wants repeatable release review.

Evaluation Pack

Start with the proof material buyers actually ask for.

Use these pages together when comparing against cloud-first obfuscation services, npm-first tooling, or broader runtime protection platforms.

Frequently Asked

Questions this page gets asked

Do you hold SOC 2 or ISO 27001 certification?

No. We do not currently hold an independent SOC 2 or ISO 27001 attestation, and this page says so rather than implying otherwise. What is published instead is the material a reviewer actually needs: how source handling works on each protection path, what release validation is expected to cover, and where support and contact channels sit. The compliance reporting in the CLI documents how the tool helps you meet your own controls; it is not a third-party certification of JavaScript Obfuscator itself.

Does my source code leave my machine when I protect it?

It depends on which path you use, and the difference is deliberate. The online tool, the API, hosted desktop mode and default npm protection send selected JavaScript to the hosted service. WinUI Local Standard, paid WinUI Local Advanced, and the npm CLI run with the local flag protect on your own machine after a source-free plan check. Local preflight commands never upload source, and in desktop mixed-file projects the surrounding non-JavaScript content stays local in every mode.

What can I send a security reviewer before booking a call?

The security evidence hub is built for exactly this. It turns the operating model described here into reviewable artifacts covering runtime monitoring, checkout evidence, VM proof and local protection, so an engineer or procurement reviewer can work through the questions independently. Pair it with the security processing documentation for source-handling boundaries and the validation guide for release expectations.

Does obfuscation satisfy a compliance requirement on its own?

No, and treating it that way is a common mistake in questionnaires. Obfuscation is a code-protection control that raises the cost of reading and modifying client-side JavaScript. Frameworks such as PCI DSS ask for script inventory, integrity assurance and change detection, which are separate requirements with separate evidence. Protection can contribute to that evidence, particularly through build manifests and reproducible output, but the control objectives are not met by obfuscating alone.

How do I verify that a protected artifact is the one you built?

Use the manifest and a seed together. The build manifest records a source and an output SHA-256 hash for every file, so you can check the artifact you deployed against the one your pipeline produced. A seed makes protected output byte-identical for the same input and options, which means a third party can rebuild from the same commit and compare hashes rather than taking the claim on trust.

Where does obfuscation stop and server-side authority begin?

At any decision that carries financial or account consequence. Secrets, payment authorisation, identity and final entitlement checks belong on the server, because code delivered to a browser can be read and modified by whoever received it. Protection is the right control for logic that genuinely has to run on the client and that you would rather competitors not read. Layering the two is the whole point; substituting one for the other is where reviews find real problems.