Securing your express/Node.js API with Firebase auth

Nwakwoke Patrick Nnaemeka on September 23, 2019

A lot of applications, be it a mobile app or a web app have some form of authentication. If you've worked on various apps, handling authentication ... [Read Full]
markdown guide

Really great article. Learned a few things.

What strategy would you recommend we use to securely pass the user's password to the create user Route?

Would just hashing with a salt and always checking against that suffice?


Just pass the raw password to firebase auth. Firebase auth will take care of the hashing


But aren’t we sending a post request to the router? Is it a security issue at all to send the plaintext password in a post request?

I understand that Firebase takes care of the password hashing, but isn’t that generally done client side?

Thanks for helping me understand.

Hashing passwords on the client before sending them to the server? Not necessary.
Even if you are handling authentication yourself, you should still hash your password on the server.
I assume your concern is someone stealing your password, if your app’s security is compromised, then they can also steal the hashed password you are sending through the client. So there is no point really.

Would one benefit of hashing client side be that, if the app’s security were compromised, then the user’s real password wouldn’t leak?

Sorry to be overly pedantic here I’m just trying to learn.

If your authentication logic depends on the server authenticating an already hashed password from the client, then all a hacker needs is that hashed password from the client, the real password isn’t useful to the hacker at this point.

If they have a plain text password I entered and I am a normal user, wouldn’t the thought be that I’ve reused this email / password combination elsewhere?

Yeah, but if every app did authentication the same way you are suggesting then their hashed password is still all that will be needed in a case of compromise. Your client code can be accessed on the browser so your hashing algorithm isn’t really hidden. My advice to you is just always have ssl.
Hope this guides you.

Thanks for taking the time to answer these quandaries.

Last one: even if an attacker has both access to a hash and the hash function, if that hash function is secure, they still can’t reverse that to get the password, correct?


what is "setUserClaim"? As far as I can tell it only exists in this article.


Seems they use setCustomUserClaims, not setUserClaim?

Thanks for pointing this out. Corrected the typo.

Thanks, also it seems like on your frontend code that firebase.initialize(config); would now be initializeApp instead of initialize;
For a WebApp atleast.

Sorry but,

When you do:
return axios.get('https://your-api-url/articles', {headers:
authorization: 'Bearer '+ token})

You missed a bracket or two, and have not put authorization into another object inside headers. It should probably be

return axios.get('https://your-api-url/articles', {headers: {
authorization: 'Bearer '+ token}})


Great and useful article. Out of curiosity why did you opt to use the asych/await instead of the following for the checkIfAuthenticated method? Do you see any issues with this alternative?

checkIfAuthenticated = (req, res, next) => {
getAuthToken(req, res, () => {
try {
const { authToken } = req;
.then(userInfo => {
req.authId = userInfo.uid;
} catch (e) {
return res
.send({ error: 'You are not authorized to make this request' });


Why did you chose to use _ over request or req?
Just curious.


I think that’s also a paradigm in python for kind of saying, “I have to declare this variable but it isn’t used.”


Just something about parameters that i have to specify and not use


Hello! Really, appreciate this succinct guide. Any chance you have repository containing this?


I dont think you are allowed to set custom claims while you are still creating a user. Create the user first, then set a custom claim.

code of conduct - report abuse