Hi Sebastian, I wouldn't know how to start to explain all of this to a five year old. I'll try to give you a few tips (this post is probably best tagged as #help instead if #explainlikeimfive, maybe).
HTTPS
the secure version of HTTP, the traffic is encrypted using secure certificates and no one, except you and the server can see what's exchanged
Input validation
it's just what the word means, no magic here. Making sure there's no malicious strings in the input. The client knows that there's a good chance that the text sent might end up in a DB, so you want to make sure they can't send commands the server would interpret
Authentication
Do I know you?
Authorization
Now that I know you, are you authorized to go everywhere?
Security Headers
How HTTP handles security between client and server
CSRF
See input validation. The client finds out that a particular combination of strings can trigger malicious behavior in the server, then it takes advantage of it
CORS
You're at website A, should you be allowed to call website B inside my page? Why are you calling website B anyway?
CSP
"You shall not pass". This quote from The Lord of The Rings pretty much sums CSP up. It's the policy of what clients are allowed to do on this website.
Captcha
A dumb idea to ask humans if they are not robots, unfortunately it's still pretty good in most cases.
Honeypot
It's just a bait. Not really common in web development I think
thank you for that explanations, I like them! And yes, you are right, it might be a bit ambitiously for a 5 year old child. But anyway, I always felt that basic security measures for web-applications are super important and at the same time a bit hard to grasp. I think everybody should have the chance to build a (mostly) secure app independent from his level of coding-skills and even if you do not use one of the ready to go frameworks. So I tried with this post :)
I think everybody should have the chance to build a (mostly) secure app independent from his level of coding-skills and even if you do not use one of the ready to go frameworks.
I know this is not going to make me popular with people who don't like frameworks but if there's one thing that frameworks should do well is to provide secure defaults and less ways to shoot yourself in the foot. They don't always do it to be honest and you can achieve the same by composing various libraries obviously but still, frameworks are made of parts that, if used, have already solved most of the mentioned problems, especially input validation, CSRF and auth.
You are right, that is a strong argument for using ready to go frameworks! Anyway, I usually work with Microframeworks and there you pick your libraries manually, so I usually integrate CSRF-protection and validation myself. So one advice might be to use big frameworks at first and move to small ones or self coded applications if you feel firm with all that security measures. But even if the big frameworks do all that for you, then you still should get familiar with the basics at some point (in my opinion :)
Hi Sebastian, I wouldn't know how to start to explain all of this to a five year old. I'll try to give you a few tips (this post is probably best tagged as #help instead if #explainlikeimfive, maybe).
the secure version of HTTP, the traffic is encrypted using secure certificates and no one, except you and the server can see what's exchanged
it's just what the word means, no magic here. Making sure there's no malicious strings in the input. The client knows that there's a good chance that the text sent might end up in a DB, so you want to make sure they can't send commands the server would interpret
Do I know you?
Now that I know you, are you authorized to go everywhere?
How HTTP handles security between client and server
See input validation. The client finds out that a particular combination of strings can trigger malicious behavior in the server, then it takes advantage of it
You're at website A, should you be allowed to call website B inside my page? Why are you calling website B anyway?
"You shall not pass". This quote from The Lord of The Rings pretty much sums CSP up. It's the policy of what clients are allowed to do on this website.
A dumb idea to ask humans if they are not robots, unfortunately it's still pretty good in most cases.
It's just a bait. Not really common in web development I think
Hi Rhymes,
thank you for that explanations, I like them! And yes, you are right, it might be a bit ambitiously for a 5 year old child. But anyway, I always felt that basic security measures for web-applications are super important and at the same time a bit hard to grasp. I think everybody should have the chance to build a (mostly) secure app independent from his level of coding-skills and even if you do not use one of the ready to go frameworks. So I tried with this post :)
I know this is not going to make me popular with people who don't like frameworks but if there's one thing that frameworks should do well is to provide secure defaults and less ways to shoot yourself in the foot. They don't always do it to be honest and you can achieve the same by composing various libraries obviously but still, frameworks are made of parts that, if used, have already solved most of the mentioned problems, especially input validation, CSRF and auth.
Django even has a bunch of automated reminders to check your security settings: docs.djangoproject.com/en/2.2/ref/...
You are right, that is a strong argument for using ready to go frameworks! Anyway, I usually work with Microframeworks and there you pick your libraries manually, so I usually integrate CSRF-protection and validation myself. So one advice might be to use big frameworks at first and move to small ones or self coded applications if you feel firm with all that security measures. But even if the big frameworks do all that for you, then you still should get familiar with the basics at some point (in my opinion :)
Well said!