Hey all! š Iām Ryo, a Sr. Design Technologist at PlayStation. I do web dev with React/TS/Node and game dev with Unity/C#/C++/OpenGL/DirectX. Feel free to ask me any questions! š¤
Hey all! š Iām Ryo, a Sr. Design Technologist at PlayStation. I do web dev with React/TS/Node and game dev with Unity/C#/C++/OpenGL/DirectX. Feel free to ask me any questions! š¤
IP logging of users to DB + checking on registration for previous IPs
Re-captcha on the form
A honeypot (for physical forms) or CSRF (for both) to prevent brute force registration/authentication
Requiring email validation before account use
As long as any API is public there is a chance that it will be abused. It's all about reducing that chance.
The other option tends to be restricting registration -- which can hinder an apps adoption rate. Sometimes it's better to let spammers sneak in if it means real users don't get locked out.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A few things:
Thanks for some good suggestions.
I'm using JWT token for updating, deleting, getting record. I also have a endpoint for login where I get that JWT token.
I can't use JWT for inserting, because thats where a user is being created for login.
You should create a separate, non-authenticated endpoint for login -- and a separate endpoint for inserting other types of data.
It might seem like you're repeating code or something, but it's just a necessity for security.
Thanks for a great solution.
But still any hacker can misuse that login endpoint by inserting thousands of users in a minute, that is my real concern.
There are several others ways to prevent that.
As long as any API is public there is a chance that it will be abused. It's all about reducing that chance.
The other option tends to be restricting registration -- which can hinder an apps adoption rate. Sometimes it's better to let spammers sneak in if it means real users don't get locked out.