Notifications
Clear all
Topic starter
18/08/2026 2:20 pm
TL;DR: Pwtoon’s case shows how HTML5 and JavaScript products face direct exposure to reverse engineering, code copying, and asset theft when client-side code is left unprotected, according to Jscrambler. The governance question is no longer whether to obfuscate, but how to balance runtime protection, performance, and release discipline without creating fragile build pipelines.
NHIMG editorial — based on content published by Jscrambler: Powtoon protects its core IP and competitive advantage with code protection
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams protect client-side JavaScript without breaking the application?
A: Use selective obfuscation, integrity checks, and build-stage enforcement on the client-side paths that matter most.
Q: Why do browser-delivered applications create reverse-engineering risk?
A: Because anything shipped to the browser can be inspected, copied, and modified with enough effort.
Q: What do teams get wrong about code obfuscation?
A: They treat it as a one-time hiding exercise instead of a control that must fit the product architecture.
Practitioner guidance
- Protect only the highest-value client-side logic Identify which browser-delivered components create competitive advantage or expose sensitive workflows, then apply obfuscation and integrity controls selectively to those paths rather than the entire application.
- Remove secrets from browser and build artefacts Audit source, bundles, and CI/CD outputs for tokens, API keys, and privileged configuration, then relocate them to managed secrets stores and server-side execution where they cannot be copied from the client.
- Bake protection into the release pipeline Make code-protection steps mandatory in CI/CD so no production release can ship with unprotected JavaScript or inconsistent integrity settings, and verify the output before deployment.
What's in the full article
Jscrambler's full case study covers the implementation detail this post intentionally leaves for the source:
- How Powtoon evaluated client-side protection options before standardising on its chosen approach.
- The specific balance the team struck between protection strength and minimal performance impact.
- How Code Integrity fit into the existing CI/CD pipeline without forcing a heavy command-line workflow.
- The runtime protection features and dashboard workflow that supported day-to-day use.
👉 Read Jscrambler's case study on protecting Powtoon's client-side code and digital assets →
Client-side code protection: what it means for app security teams?
Explore further
18/08/2026 3:12 pm
Client-side code protection is now part of application governance, not just obfuscation. Once a product depends on browser-delivered logic, the integrity of that logic becomes part of the organisation’s control plane. Jscrambler’s case shows that competitive differentiation can be undermined when runtime code is easy to inspect and reuse. Practitioners should treat client-side protection as a governance decision tied to release risk, intellectual property exposure, and trust in delivered functionality.
A question worth separating out:
Q: How do security teams decide where client-side protection is worth using?
A: Prioritise components that carry proprietary workflows, differentiation, or high-value asset logic. If the code only supports commodity interface behaviour, heavy protection may add friction without enough security value. The decision should balance theft risk, tampering risk, and performance impact.
👉 Read our full editorial: Client-side code protection and IP theft risk in HTML5 apps
