Application without back end


I'm doing a gadget here in the company, where it consumes an API that uses JWT authentication (login done with email and password) ...

As everything I've done so far has been with PHP, I'm a bit afraid of security issues because the application is being completely done with JavaScript, HTML, and CSS.

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


  • Is it safe for multiple users to get their tokens stored in cookies?
  • Requests (AJAX) are exposed in the code, is this harmful?
  • What I did before in the back end with PHP I'm doing in JS, is it harmful too?
asked by anonymous 06.09.2018 / 21:05

1 answer


Is it safe for multiple users to get their tokens stored in cookies?

It is important to note the security recommendations that involve keeping session identifiers - and similar data - in cookies. In this MDN session you get some information on what you can do: link In summary, you need to use the flag httpOnly so the cookie is not accessible via JavaScript, which helps prevent session theft.


AJAX requests are exposed in the code, is this harmful?

Whatever happens on the client gets exposed, it is not necessarily harmful. As long as the APIs you consume are protected by authentication and authorization, that's fine. Another key practice is the use of https to prevent others from analyzing your app's information traffic and stealing the users session. In addition to the link flag mentioned above, it is important to add the secure flag, which defines 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, is that harmful too?

It depends. Your business rules should always be in the backend, regardless of how you put them in some way on the front end as well.

Here's an example:

Imagine you have a virtual store. And 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, it just persists the data.

Hence a malicious user can analyze the requests that your front does for the API and find out how the discount information and prices are sent. Then he can make a request for his API, without using the web application that you developed with js, adding 50% discount buying only 1 product. Since the API does not validate, the user was able to buy a product for a price well below that advertised improperly.

All validation, verification and application of business rules must be done in the API, you should not rely on the information that the screen sends. Some rules you get put on the front, like the discount issue I put up. Sometimes it is useful since you can warn the user that if he buys a more drive gets discounted, but this does not detract from the API's responsibility to do the verification too. The same goes for, for example, form validation, such as mandatory fields, whether the email is valid, whether the age is a positive number etc.

16.10.2018 / 13:35