How SecureJS Protection Works

SecureJS protects JavaScript by separating the protected script from the private material needed to unlock it. The file placed on a website contains the encrypted payload, integrity checks, and runtime loader. It does not contain the author secret key.

The Protection Flow

1. You paste valid JavaScript into the SecureJS console.
2. You enter your author email, licensed domains, and a strong private key known only to you.
3. SecureJS uses the private key to prepare a protected payload and stores the unlock material server-side.
4. The generated script is added to the authorised website.
5. When the script runs, it requests a short-lived unlock response for that specific payload and domain.
6. If the domain is licensed, the runtime decrypts the payload in the browser and executes the original JavaScript.

What the Key Does

The author key is the private root of the protection process. Under the intended operating model, the original author keeps that key private and never shares it with customers, site owners, or end users. The deployed JavaScript therefore cannot be reversed from the page source alone, because the material needed to unlock it is not shipped inside the file.

Authorship Watermarking

SecureJS embeds authorship metadata inside the protected payload. The watermark is not visible in the deployed script source, but it travels with the protected code and can support ownership checks when a protected payload is investigated.

What This Protects Against

• Copying the protected script from an unauthorised site and reversing it from source alone.
• Running the protected script on domains that are not licensed for that payload.
• Casual source inspection, formatter tools, static deobfuscators, and simple key extraction attacks.
• Undetected tampering with the encrypted payload or unlock response.

HTML, PHP Pages, and Linked Files

SecureJS can process complete HTML and PHP pages by protecting inline JavaScript while leaving the HTML and PHP structure readable. Linked JavaScript files are handled as separate protected files, then referenced from the page with a normal script src tag.

HTML Armour is a separate mode for lighter page-level protection. It minifies markup, encodes visible text as mixed HTML entities, compacts inline CSS, protects inline JavaScript where present, and adds copy deterrents for casual reuse.

For module scripts, import lines remain readable by design. This allows browser-managed dependencies such as CDN imports to load normally before the protected JavaScript body is unlocked.

Important Limit

Any JavaScript that runs in a browser must eventually exist in executable form inside that browser. SecureJS is designed to stop unauthorised reversal from the copied source file, not to make client-side JavaScript mathematically impossible to inspect after it has been authorised and executed.

Where SecureJS is materially different from ordinary obfuscation is the copied-file attack. Without the author key and a valid hosted unlock response, an attacker is pushed toward brute-forcing the private key material rather than simply formatting the downloaded source. With a properly random 256-bit key, even at 100 guesses per second, a full key-space search is around 3.7 × 10⁶⁷ or Thirty-seven unvigintillion years, with an average successful search still around 1.8 × 10⁶⁷ or Eighteen unvigintillion years. Weak or reused human passwords do not provide that level of protection, so production builds should use generated high-entropy keys.

Guest vs Registered

• Guest: limited trial use for small scripts.
• Registered: larger payloads, saved records, and audit visibility.
• Commercial: higher limits and hosted unlock support for production use.
• Enterprise: larger deployments, domain control, and operational support.