The one thing that developers tend to considers at the end of the development cycle is the “security” of the application. A secure application is n...
For further actions, you may consider blocking this person and/or reporting abuse
Shahid Shaikh on December 30, 2020
For further actions, you may consider blocking this person and/or reporting abuse
A lot of this is very good advice. However I would add a couple of things:
SameSite=Strictand you really should be setting this to be true for all cookies. (This was missed when talking about cookies, and it is really easy to do.)bcryptset up that was suggested here is now no longer the best practice, it's argon2, although at some point that will also be not the best solution either.I would never consider it a good practice to force anyone to use social sites if they want to use a webapp.
As an optional alternative, sure (personally I wouldn't offer FB login at all and I would never use sites that need it, but that's just me) but not as a full replacement.
Oh, so you want to browse my blog / shop in my store but first you must hand over your data to Facebook / Google. Because security.
Totally agreed. A password-based auth might be old but still works great.
for sure, even if is just one of the steps to log... I really like it yet
That's because most companies are not security competent. Sure I would never hand my data over to Facebook, but Google has proven they don't know what do with it anyway. Realistically you must trust some repository for storing access credentials. Using federated login is much safer than using Lastpass, 1Password, etc... If you want a privacy first federated login, come talk to me in a couple of months, Authress will have that capability.
If you don't use a social login, the site you are using will most likely leak all your data. And sure for a blog you can argue nothing bad, but a site that I put my credit card in, I would never trust that site to handle my data correctly. It usually ends up like this: Hacked home cams used to livestream police raids in swatting attacks.
For credentials, sure. But social login doesn't come with simply credentials storage but with an agreement to allow monitoring online behaviour to the extent that a user needs to put in place a lot of serious safeguards to protect their data and prevent traces, doubly so if they have social media presence.
Without social media profile, some generic data can be leaked, but it's much easier to prevent it even with basic modern browser enhancements.
Password storages, I trust (so far) which is why I prefer the password storages + generated password rather than social login.
I would go password less for 2021, people are just dumb with passwords.
Unless you mean biometrics, I don't see how that goes. Social login means the password is handled by Facebook. But it's still a password just somewhere else, incidentally with a bigger footprint, a bigger target both for hacking and phishing. I have nothing against providing social login as an alternative, just not a replacement for user password (with 2fa, maybe).
If there's a breach on their side, you can't do much except remove that provider.
Totally agreed.
Just email magic links in that case :). Passwords are deprecated.
Absolutely, password are deprecated. That's why nobody uses them anymore and the very few websites that use them are compromised 10 times a day.
Just gonna send an email link to an email address based solely on the existence of that email, which the user is going to access with a ... password. There, the bucket was kicked down the road a bit more.
Points:
"That's why nobody uses them anymore and the very few websites that use them are compromised 10 times a day" - What is your source for these facts, or are they just opinion?
sarcasm
Ok. Funny then but not helpful.
That's what the second part of the post was for. Unless you're looking for validation.
I did a fair bit of reading on CSRF. While we should always try and use
SameSiteattribute for cookies, it is not a fool-proof method for protecting against CSRF. CSRF token should still be used. TheSameSite=Strictwill only work for browsers that implement this feature. If a user uses a browser which does not support it, they can be vulnerable. Additionally there are ways to bypass this feature even for browsers supportingSameSiteattribute.Quoting from CSRF sameSite:
If you are using REST APIs to secure content and not sending it back as part of a SSR. Then those bypasses don't apply. Since it isn't secure to send content back as part of page navigation anyway. CSRF can entirely be replaced by
SameSite.I would argue that many things you list are controversial.
First, not everybody is building secured services on cloud, and many developpers are building in enterprise private infrastructures.
For many of us:
i appreciate your suggestions but here is my reverse suggestion for webauthn caniuse.com/?search=webauthn check it out, very incompatible on many browsers
Nice work brother. I am making this post more visible.
Also for those who are looking for mongodb security? I have posted a completed write up here: dev.to/tbhaxor/one-step-to-prevent...
Also for express js users, I have created a middleware: mongo-secure.tbhaxor.com/
Great list, and very timely for me. I was asked recently on a call what backend security techniques I am familiar with. On the call I remembered about 1/2 of these, so it’s good to see a full list.
I’ve used all of these apart from perhaps the regex denial of service detection.
Some other libs worth considering:
i have a question here, will highly appreciate the answer by anyone. what is the point of
express-bruteif not been able to use it in production? Thanks.it's for the demonstration purpose. You can use the rate-limiter technique of a similar kind in the production server.
Or maybe having it built. Thanks.
This is a great piece! Thank you. Security still seems to be underemphasized in dev curricula. For many devs, when it comes to learning about security, we don't know where to start. Do you have any pointers/suggested resources on how to get started on cybersecurity?
Start with hacking first (ethical one for sure), learn how to hack a web server, how to scan it for vulnerabilities, look what typical vulnerabilities exist and how to exploit them, it'll give you a lot of knowledge and motivation to create more secure services and websites :). I can send some resources if you're really interested!
Cool Post, thank you very much!
Your welcome :)
Good job brother, appreciate all the efforts!
Great article. I will definitely consider these in my next project.
Great collection of security practices! Thank you for taking the time to write this. 👍
Your welcome. It took me almost a month to compile it :)
Securing application in the best way👍
This is really good. I really appreciate your effort to put these things together.
Great post, fantastic comments. Lots of views!!!
Very useful info here. I learnt new things. 😇
Please don't limit the length of your password to so low a value! If the complaint is that users choose bad passwords, at least give them a chance to prove you wrong instead of ensuring they can't.
Great collection
Total great!!! Thank for your writing!