I’ve mentioned Cross-Site Scripting, aka XSS, in some of my previous posts. And I’m sure you’ve heard of it as well.
XSS is often categorised as either reflected XSS or stored XSS. And then DOM-based XSS was added. OWASP now categorises XSS as:
Both of these can be either reflected or stored, which can make it all a little confusing.
No, we are not talking about delicious double-chocolate cookies. Although I’ve really missed the fabulous Incus Data cookies during lockdown.
As you know, cookies are small text files. They are usually created by the web server, but are saved and managed by your browser.
Cookies can be harmless or incredibly dangerous. It all depends on how you use them.
I believe in code re-use. You believe in code re-use. No-one wants to re-invent the wheel, especially not if there is a really great, aero-dynamic, ultra-fast wheel available.
That’s why we use libraries and components. But those libraries and components are not written by super-humans. They are written by people like you and me – people who make mistakes.
In a previous post, I told you about the importance of using HTTPS instead of HTTP. Today I will look at some of the functionality that HTTPS adds in the form of security headers.
You might have heard the term “data sanitisation” applied to devices. We need to permanently remove data on portable storage devices and hard drives before we get rid of them.
But today I want to talk about a different form of data sanitization: input sanitisation.
The question you need to answer is this:
How clean is the data that you are saving in your application?
This is a very important question.
How do you know if something has gone wrong, or if your site has been compromised?
The answer is that, unless you are logging and monitoring events, you don’t know.
If you read about major data breaches, you’ll notice that often the data breach might have been going on for years. The companies only noticed it when someone complained.
According to a 2020 IBM Security study, companies in South Africa took on average 177 days to identify a data breach. That might not be years, but it is still way too late.
You’ve visited a building where you need an access card. Without the card, you don’t get in. But the card doesn’t (or shouldn’t) open all doors once you are in the building. Some areas must be off-limits. That’s physical access control.
Digital access control works on the same principle. It controls who can access the system, and what they can see once they are in.
HyperText Transfer Protocol (HTTP) is the network protocol that allows your browser to communicate with a web server. HTTP makes it possible to send and receive information across the internet.
HTTPS is the secure version of HTTP.
For a long time, you only needed HTTPS if you used sensitive data that needed to be secure. That’s not true anymore.
As a user, you need to manage your passwords. (If you are struggling with that, read our blog post about password managers.)
As a developer, you have a much greater responsibility. You are the Guardian at the Gate: it’s your job to keep your users’ passwords safe from potential attackers.
So how are you storing those precious passwords? Let’s take a quick look at some options. Continue reading