12

Description

I'm designing a Node.JS application (more like a full website). The app will send five JavaScript files and will have <script> tags linking them together.

Question

How can I prevent users and attackers peering and editing my code?

  • An example would be:

    • Ctrl + Shift + I

    • In Devtools, goto Sources, select a file to edit (i.e index.html) and write edits

    • Pressing Ctrl + S will cause Live editing to occur

I would like to prevent The above example from happening... Is it possible?

Here is what I thought:

I'll create another client side JavaScript file, prevent_keys.js

It will listen for Ctrl + Shift + I.

If it returns true (i.e the keys were pressed), it will log the keys.

However that won't stop the user from using Devtools directly.

Community
  • 1
Ed The ''Pro''
  • 253
  • 3
  • 10
  • 16
    You cannot prevent anyone from seeing or modifying your javascript that runs in the browser. Can't. – jfriend00 Oct 28 '18 at 18:52
  • 7
    Just because the answer to a question is “You can’t.”, doesn’t mean it should be downvoted. – RubberDuck Oct 28 '18 at 19:48
  • 1
    Very closely related question: [JavaScript only validation on AJAX form submit](https://softwareengineering.stackexchange.com/q/364625/121035). Especially check out the [accepted answer](https://softwareengineering.stackexchange.com/a/364630/121035) with its trivial example of how to send a POST call that, to your server, looks identical to one that came from your client, despite not even coming from a web browser. – 8bittree Oct 29 '18 at 19:34

3 Answers3

37

You literally cannot prevent users from accessing and modifying content that you are sending them. You have no control over the browser, or which browser they use, or whether they are in fact downloading your source code via a browser. You are executing your code on another person's device. You should not and cannot assume anything about the integrity of this device.

If you have code that you don't want to have exposed, do not send it to the browser. Instead, let the browser send a request to a server where you execute the secret code.

As a concrete example, do not check passwords on the client. The client could be modified to always tell the server “the password was correct”. Instead, authentication must happen on your trusted server.

amon
  • 132,749
  • 27
  • 279
  • 375
23

You can't. One of the fundamental rules of computing: you can't trust the client. Whatever clever scheme you think of, I can get round it if I am in control of the client.

Philip Kendall
  • 22,899
  • 9
  • 58
  • 61
  • 2
    I've moved all validation, uploading, downloading, userAccouts() handlers to the server's include. – Ed The ''Pro'' Oct 28 '18 at 19:12
  • 1
    "You can't trust the client" is just one side of the coin. The other side says: "You are not the owner of the client". The browser that runs your javascript is not yours, the OS that runs the browser is not yours, and the hardware that the browser runs on is not yours. **Whatever the owner of this stuff happens to do with the data you send to them *is none of your business*.** It is a matter of respect for your clients to not try to usurp their stuff. – cmaster - reinstate monica Dec 23 '18 at 17:41
2

Why don't you want the code to be modified?

Security? Trust? Trade Secret?

Then don't send the code, get the client to send a request, and return a result. Maybe not a private or privileged result, just a done is sufficient for many UIs.

Because slightly modified versions of your own code are hurting your bottom line?

Use a code obscurer, name mangler, and trivial code segments.

These techniques raise the bar on actual skill level, and tooling required to make a slight variant of your website. Just be aware that these techniques can make your code slower, can introduce interesting and meaningless bugs and error messages, and yet still can be overcome by someone with the right tools and/or skills. So really consider if that is worth it. At the end of the day anyone could just actually write the same code.

Kain0_0
  • 15,888
  • 16
  • 37