Yes, I am your super nerdy child and proudly present you my first self-coded web application. Of course I want to publish it live and show it to all my kindergarden-friends. You are super proud, but you also want to prevent me from a security-nightmare with my first running web-application. Your child wouldn't be such a lovely nerd if it had not already duckduckgone some security-related terms. Now it is your turn to explain what it means, what it prevents from and how it works (super basically):
- HTTPS
- Input Validation
- Authentication (oauth, JWT, more?)
- Autorization
- Security Headers
- CSRF
- CORS
- CSP
- Captcha
- Honeypot
... and maybe you are missing some very basic random stuff that is important to know before I go live?
Top comments (8)
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!
To put some of those terms in 5-year-old terminology:
Sarah's lunchbox is unlocked. Trevor, the class bully, was able to open up the box and steal her cookie. (HTTP)
Tommy has a fancy lunchbox with a combination lock. If you want Tommy's cookie, you're going to have to ask him for it. Tommy isn't going to share his cookie with you if he doesn't trust you, and you won't be able to get to it without Tommy's permission. (HTTPS)
For the first week of class, everyone wears a name tag so you can learn everyone's name.
Everyone's name tag also lists that students' allergies, and any medications they need throughout the day. At snack time, the teacher looks at your nametag to see if you can have Goldfish (which has gluten), or if you instead need the gluten-free fruit snacks. Likewise, the school nurse looks at your nametag at lunch to see if you have medications that you need to take then.
At naptime, every kid is supposed to lay down on a floor mat with a pillow and blanket and rest for a little while. One day, you stuffed the blanket with extra pillows so it looked like you were under it, when in reality you were hiding in the corner quietly drawing with crayons.
Your teacher walks by each student as they lie down and asks them a question, to make sure they're actually under the blanket. As you just stuffed your blanket with a pillow, you couldn't respond to the question, and so your teacher knew it wasn't you under the blanket.
The https analogy is kinda off, it doesn't make your 'lunchbox' inaccessible to others;
for the sake of the analogy, Tommy leads you to a backroom so no one but you sees what kind of cookies he decides to share with you
Great, I love that !!! :D