Application without Back-end

Asked

Viewed 173 times

4

I’m doing a mini-application here at the company, where it consumes an API that uses JWT authentication (login done with email and password)...

As everything I’ve done so far was with PHP, I’m a little afraid of security issues because the application is being done completely with Javascript, HTML and CSS.

Note: Whenever the token wins, the application deletes the cookie and asks the user to enter email and password again.

Doubts:

  • It is safe for multiple users to keep their tokens stored in cookies?
  • Requests (AJAX) are exposed in the code, this is harmful?
  • What I did before in the back end with PHP I’m doing in JS, this is harmful too?

1 answer

1


It is safe for multiple users to keep their tokens stored in cookies?

It is important to look at security recommendations that involve keeping session identifiers - and similar data - in cookies. In this session of MDN you get some information about what you can do: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Security In short, you need to use the flag httpOnly so that the cookie is not accessible via Javascript, which helps prevent session theft.

Requests (AJAX) are exposed in the code, this is harmful?

Everything that happens in the client is exposed, not necessarily harmful. As long as the Apis you consume are protected by authentication and authorization, it’s no problem. Another fundamental practice is the use of https to prevent other people from analyzing the traffic of information from your application and stealing the session from users. In addition to the flag httponly above, it is important to add the flag Secure, setting that the cookie will only be sent to the application - the API in this case - if the connection is via https.

What I did before in the back end with PHP I’m doing in JS, this is harmful too?

It depends. Your business rules should always be on the backend, regardless of whether you put them somehow on the front end as well.

Let’s go to an illustrative example:

Imagine that you have a virtual store. And that there is a rule that applies 20% discount whenever the consumer buys more than 3 items. Also imagine that this rule is calculated on the front end and that your API does not check, only persists the data.

Hence a malicious user can analyze the requests that your front end makes to the API and find out how discount information and pricing is sent. Hence it can make a request for your API, without using the web application you developed with js, adding 50% discount by purchasing only 1 product. Since the API does not validate, the user was able to buy a product at a price well below advertised improperly.

All validation, verification and application of business rules should be done in the API, you should not rely on the information that the screen sends. Some rules you manage to put on the front, as the question of the discount I put above. Sometimes it is useful because you may warn the user that if they buy one more drive they get a discount, but this does not take away the responsibility of the API to do the check as well. The same goes for, for example, form validation, such as mandatory fields, if email is valid, if age is a positive number, etc.

  • Well each request is analyzed by the API in a way that neither validated with JS, when it gives some error or some data is invalid, just forward the message that the API returns to the user, so there is no problem right?

Browser other questions tagged

You are not signed in. Login or sign up in order to post.