0

I hope everyone is doing okay.

I've built a React.js website which is hosted in a server with SSL, but I'm not sure whether it's secure or not. That's why I decided to ask you for some advice/tips or solutions that will make my website secure.

In this app, I require the user to log in. After the user logs in, my app proceeds to send the credentials (with a Post Request) to my backend server, which is an API hosted in another domain. Then my API uses the post request data for web scraping and eventually returns some data to my frontend.

In the whole process, the only important data are the login credentials. What I did so far to make my website more secure was:

  • Using SSL both on my backend and frontend
  • The app does not hold any data (it doesn't have a database, it doesn't use cookies, etc.)
  • I limited the number of requests that can be made to my backend server in a second/minute/hour/day.
  • I only use one post request to transfer data between frontend-backend. (frontend sends a post request, backend sends a post request to the website that needs to be scraped, and returns frontend's post request with scraped data)
  • I don't know the use of this but I read somewhere that using With Credentials in your post request makes it more secure? (I'm not sure about this one.)

(Also, it will be an open-source project, so people will be able to see ) I read that SSL will encrypt my post request, I also used Fiddler to see whether it's encrypted or not, it was.

Is it possible for individuals with malicious intentions to trace the data I send with the post requests?

Do you think it's secure enough?

Thanks

0

Sinse you don't see any cookies, means you store user credentials on the client. It means that either you ask user for credentials for every single request, which is a poor usability. Or you have fields for user and password, user enters these data once and they remain in the current page the whole time over multiple requests. If this is true, this is not a good approach. Such sensitive data should be kept as short time as possible, because otherwise there is a risk that somebody else will know them.

SSL (or very probably you use TLS) ensures that nobody else can decrypt the traffic.

On the server side there can be some risks. Normally certificates are installed on a separate server, before the server where the application is running. The way between server with certificate and your application remains unencrypted. If there are no other users in your environment, this is not a big problem. But if there are other users, then there is a risk that some users can read your unencrypted traffic on the server side.

  • Thank you. I use input fields and yes users need to re-enter their credentials if they refresh/close the page; which I actually did on purpose to not save any cookies since I heard that cookies shouldn't hold any sensitive information and I thought it was more secure this way. Thus, I am holding the credentials data as a state in the current session, and it's on the client until the user refreshes/closes the page. So I will try to reset them once the user logs in. Is this a better approach? Also, I didn't understand "other users in your environment", what do you mean by that? – atahanksy May 13 '20 at 22:34
  • 1) Keeping user and password the whole on the client is risky. 2) By other users I mean a case when there are multiple applications running (e.g. cloud or cluster) and many developers or admins have access to this environment, e.g. for deployment, for configuration, for log analysis etc. Potentially all of them can intercept unencrypted traffic between SSL end point and your application. – mentallurg May 14 '20 at 3:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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