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.

3
  • 16
    You cannot prevent anyone from seeing or modifying your javascript that runs in the browser. Can't.
    – jfriend00
    Oct 28, 2018 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, 2018 at 19:48
  • 1
    Very closely related question: JavaScript only validation on AJAX form submit. Especially check out the accepted answer 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, 2018 at 19:34

3 Answers 3

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.

2
  • 4
    "The client could be modified to always tell the server “the password was correct”." cough libssh cough Oct 28, 2018 at 18:39
  • Thanks a lot! I was sending handlers for login, logout and sign up. I have changed it to routes in the server. Oct 28, 2018 at 19:09
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.

2
  • 2
    I've moved all validation, uploading, downloading, userAccouts() handlers to the server's include. Oct 28, 2018 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. Dec 23, 2018 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.