Notifications
Clear all
Topic starter
18/08/2026 2:14 pm
TL;DR: MeDirect says multi-layer code protection reduced the attack surface of its banking application by making logic harder to reverse engineer, while preserving performance and fitting into CI/CD workflows, according to Jscrambler. The deeper lesson is that application security controls must protect executable logic, not just the perimeter, because exposed client-side code can become an access path.
NHIMG editorial — based on content published by Jscrambler: MeDirect Protects its Source Code with Jscrambler Code Integrity
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, or revealing access credentials.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should teams protect client-side application code from reverse engineering?
A: Use layered controls such as obfuscation, code hardening, and tamper resistance, but do not rely on them alone.
Q: When does code obfuscation help security, and when is it not enough?
A: Obfuscation helps when the goal is to raise the cost of reading or instrumenting exposed code.
Q: What should security teams look for in application integrity testing?
A: Focus on whether protected code can be altered, bypassed, or used to infer hidden control flow.
Practitioner guidance
- Map exposed client-side logic to abuse paths Review banking and customer-facing applications for authentication, session, and transaction logic that is shipped to browsers or mobile runtimes.
- Test reverse-engineering resistance before release Run penetration tests, code reviews, and tamper checks against obfuscated builds to see whether protected scripts still reveal meaningful logic or can be modified for abuse.
- Measure security impact against delivery friction Validate that code hardening and obfuscation do not introduce performance regressions or pipeline bottlenecks that encourage teams to bypass the control.
What's in the full article
Jscrambler's full article covers the operational detail this post intentionally leaves for the source:
- How MeDirect integrated Code Integrity into its CI/CD pipeline in minutes without disrupting delivery
- The specific testing checklist MeDirect used to validate penetration resistance, vulnerability scanning, and code review outcomes
- The performance and file-size considerations the team evaluated before adopting the protection layer
- How polymorphic JavaScript obfuscation and code hardening were combined to frustrate reverse-engineering attempts
👉 Read Jscrambler's analysis of code integrity for MeDirect's banking application →
JavaScript obfuscation for banking apps: what should security teams verify?
Explore further
18/08/2026 3:05 pm
Source-code exposure is a control problem, not just an intellectual-property problem. When application logic is visible to attackers, the issue is bigger than copying code. Exposed logic can reveal authentication flows, transaction checks, API usage patterns, and abuse paths that help attackers automate fraud or tampering. For banking and fintech teams, that means application protection belongs in the same risk conversation as access control and transaction security, not only secure development.
A question worth separating out:
Q: How do application security and IAM teams share responsibility for exposed code?
A: Application security owns the integrity of the delivered code, while IAM owns the trust placed in authentication and authorisation decisions. Both teams should review where the client is being asked to enforce security logic, because those are the points most likely to be probed or reversed.
👉 Read our full editorial: Source code protection for banking apps must outpace reverse engineering
