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.

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. Online, desktop, API, and npm protection send selected JavaScript to the hosted service. Desktop is the visual path for larger folders and mixed-file review; local preflight commands do not protect code.

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. Online, desktop, and CLI protection send selected JavaScript to the hosted service. 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, note that current protection workflows send selected JavaScript to the hosted service. Confirm that data flow is permitted before submitting regulated or sensitive source.

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.