How to write secure Javascript?

Hey there,
Currently I’ve a simple project where there is a button and dynamically updated UL list.

Whenever user clicks on a button an AJAX request is sent and in server unique ID is generated and inserts a new record in DB, (no user data entered in that row only the unique ID is inserted) and the unique ID is returned as response.

So. user can modify the unique ID and try to malfunction the system, How do I prevent this?

I mean how we can complicate the Javascript for the end-user to understand, any thoughts?

In short, by Authorisation (for which there are several implementation strategies)

What is the unique ID for? What would happen if the user changes the ID?

IMHO, “secure JavaScript” is an oxymoron.

I think security has improved a lot over the years. But the fact is that anything that happens on the client side can be altered on the client side. It might be so complicated that one would need to be very determined to figure out how to hack it, and for many cases it is the “easy” vulnerabilities that get exploited first. But if someone is determined enough, the risk they will succeed is there.

There must be server side measures in place if security is to have any real chance of being secure.

2 Likes

It is used to create quizzes basically and I think if somehow user get to know other quiz ID (of other users) and try to modify then…

I know the concept of validating again on server side but is there any way of hiding such attributes (data-id) from directly placing on elements and using some kind of hidden method to uniquely assign an ID sent from server to the specific DOM Node?

You could set it to a hash. Hash values can’t be as easily guessed like 234, 235, 236 … can.

When the hash is sent to the server, the server matches eg. “a24fb8736ac …” in the database to “459”

3 Likes

You should not complicate for the end user to modify the Javascript. You should accept that the front-end is fundamentally modifiable by the end user.

Security in the front-end is to protect the user from other people. The connection to the server can be encrypted. Authentication can be in place to make sure of the user’s identity.

Besides, you said that a request has a direct impact on your database causing inserts. This is a weakness. If you cannot trust the end user and he can do things that corrupt your server, your setup must be rebuilt.

The end user can insert in your database via a request. And you don’t want the user to customize his request, like change the ID.

It is very common for session cookies to be stored in in-memory caches like redis.

3 Likes

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.