Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
Nice write up. I'd add something though. I never return a 401 if the user unauthenticated. Return a 200, let the hacker think they succeeded, it slows them down a lot more than if you tell them they failed.
Better yet, return a fake object, or make your endpoints check for a specific response value and redirect them to the login screen forcing them to start over.
Personally for all hack attempts I capture I now return the message "invalid token", except the project I'm working on doesn't use a token. Can't wait to get support requests asking me where they can find their token as no actual user would ever encounter those messages without digging in the network tab.
Better yet, I've seen people propose that when your endpoint detects a bot, don't respond and don't time out, leave it hanging, waiting endlessly for a response that never comes.
If someone wants to hack you, make it hard on them, but also fun for you :)
Interesting! So in the case the front end relies on 401 (for example when fetching a refresh token) do you then hide some clues in the response so that the front end will know when to fetch another refresh token ?
Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
In that case you could just add a value to the object like "message":"nogo" and use that to determine it, but since all failed responses return the same message it throws a potential hacker off the scent since there's nothing useful to it.
Nice write up. I'd add something though. I never return a 401 if the user unauthenticated. Return a 200, let the hacker think they succeeded, it slows them down a lot more than if you tell them they failed.
Better yet, return a fake object, or make your endpoints check for a specific response value and redirect them to the login screen forcing them to start over.
Personally for all hack attempts I capture I now return the message "invalid token", except the project I'm working on doesn't use a token. Can't wait to get support requests asking me where they can find their token as no actual user would ever encounter those messages without digging in the network tab.
Better yet, I've seen people propose that when your endpoint detects a bot, don't respond and don't time out, leave it hanging, waiting endlessly for a response that never comes.
If someone wants to hack you, make it hard on them, but also fun for you :)
Interesting! So in the case the front end relies on 401 (for example when fetching a refresh token) do you then hide some clues in the response so that the front end will know when to fetch another refresh token ?
In that case you could just add a value to the object like "message":"nogo" and use that to determine it, but since all failed responses return the same message it throws a potential hacker off the scent since there's nothing useful to it.
neat! thanks for the tips! :)