How to Protect Your Software in the Age of AI Reverse Engineering: 10 Practical Measures

In brief: Every part of an application that goes to the user's device or browser, meaning bundled JavaScript, mobile app packages (APK/IPA), desktop (Electron) apps and network traffic, can be inspected. AI-assisted reverse-engineering tools like REA speed up that inspection (what is REA?). That does not mean “software can't be protected;” it means putting things in the right place: secret keys, pricing/business rules and licence checks should live on the server; the client should hold only what is harmless to expose. Code obfuscation makes inspection harder and slower but does not prevent it. This article gives 10 practical measures and the limits of each. Information is based on general engineering principles and sources published as of 23 October 2026.

Last updated: 23 October 2026

The basic principle: everything sent to the client is readable

JavaScript delivered to your browser, an app package installed on your phone or a desktop program downloaded to your computer is under the user's control. REA's official repo lists these classes as targets: JavaScript/Electron apps, .NET, Android APKs, websites and native binaries. In an independent test the tool listed the communication channels inside an Electron app, with correct locations, in seconds (test summary). So the question is not “can it be read?” but “what harm does it do when read?”

10 practical measures

1. Don't put secret keys on the client

API keys, database passwords, payment providers' secret keys and AI services' keys must never be in browser code, a mobile app or a desktop package. They belong on the server; the client should talk only to your server. (Keys designed to be “public,” such as map keys restricted to specific domains, are a separate category; they should still be restricted.)

2. Run business rules and pricing on the server

If discount calculation, commission rates, authorisation decisions, quotas and licence checks are done on the client, the user can change or skip them. The decision should be made on the server; the client should only show the result. This is especially critical for plan/payment limits in SaaS products.

3. Verify authorisation on the server in every API call

Hiding a button is not authorisation. On every request, the “can this user do this?” check must happen on the server. Someone who inspects client code sees all the endpoints (API paths); an unprotected endpoint can be called directly. For details, see our web application security guide.

4. Add rate limiting and abuse protection to your APIs

Someone who understands your application's internals can call your API automatically. Rate limiting, anomaly detection, authentication and, where needed, bot protection make bulk data scraping and abuse harder.

5. Use obfuscation with realistic expectations

Minification and obfuscation make variable names meaningless and slow down inspection. But they do not make a determined analyst's job impossible, especially if tools can trace behaviour and find the relevant code paths. Treat obfuscation as an extra obstacle, not your only protection. Also don't publish source maps for production to everyone.

6. Move sensitive algorithms to the server where possible

If your competitive advantage is a calculation algorithm or a model, rather than sending it to the client, expose it as an API. The user gets the result; the method stays on the server.

7. Layer integrity and licence checks in mobile and desktop apps

Measures such as app signing, integrity checks and certificate pinning can make modified copies harder to run; but they are not enough on their own against a determined attacker. Keep licence verification on the server side and monitor abnormal usage (such as one licence running on many devices).

8. Secure your dependencies and release process

Your application contains many open source components. An attacker can target not the code you wrote but the dependencies. This week's LiteLLM supply chain attack showed it. Version pinning, an inventory and protecting the release process are part of this work.

9. Don't neglect legal protection

Technical measures complement legal protection rather than replace it. In your terms of use and licence agreements, regulate reverse engineering, copying and redistribution; and make source code and intellectual property clauses clear in contracts with customers and software suppliers (our contract checklist). Which forms of inspection may be lawful varies by country and contract: see our article on legal limits and consult a lawyer.

10. Think through the “what if it's copied?” scenario in advance

Client-side features (interface, flows) can be imitated. Your real competitive advantage usually lies in data, brand, customer relationships, speed and continuous development. Protect your critical assets (data, models, business logic) on the server and focus on developing the product fast. Write down in advance what you will do if there is an incident (a leak, a copycat product): who will be informed, which keys will be rotated, what the legal step will be.

Quick checklist

• No secret keys in client bundles (JS, APK/IPA, desktop)
• Pricing, authorisation, quota and licence decisions on the server
• Server-side authorisation on every API call
• Rate limiting and abuse monitoring in place
• Source maps not publicly available in production
• Sensitive algorithm/model on the server
• Licence verification on the server, abnormal use monitored
• Dependency inventory and version pinning in place
• Reverse engineering and copying clauses in terms/contracts
• A written incident plan for a leak/copycat scenario

Secure architecture with Aktaş Digital

In new projects we settle in the architecture phase which logic stays on the client and which on the server; for existing applications we can also review secret keys, authorisation and API security. To describe your project and get a scope and cost breakdown, you can use our quote form. Related services: web applications, SaaS platform development and AI solutions.

Frequently Asked Questions

Does obfuscation fully protect my application?

No. Obfuscation makes inspection harder and slower but does not stop a determined analyst. Real protection is that sensitive logic and keys never go to the client at all.

Can anyone see my website's JavaScript?

Yes; JavaScript sent to the browser is readable by the user. That is why secret information and critical decisions must be on the server.

Is the API key in my mobile app safe?

Keys embedded in an app package should be considered extractable. Keep secret keys on the server; restrict by scope and quota any keys you must use on the client.

Have AI tools increased this risk?

They speed up inspection and let it be started with less expertise; but the basic risk is the same: everything sent to the client is readable. So the principles above applied before AI too; now they matter more.

What can I do if a competitor copies my app?

It depends on the country, the contracts and what was copied. Keep the evidence and consult a lawyer. As prevention, review your terms of use and licence provisions.

Conclusion

AI-assisted reverse-engineering tools make the assumption “nobody will look” invalid. The answer is not paranoia but right placement: everything that must be secret on the server, only what is harmless to expose on the client. The first thing you can do today: ask your software team to check whether your application's client packages contain secret keys and business rules, and to share the result in writing.