Last week I wrote about Cross-Site Scripting, and the serious consequences it can have.
According to OWASP, XSS affects about two thirds of all applications. That statistic should scare you!
Now that I have your attention, let’s look at how we can stop XSS.
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.
I mentioned before that I am writing an online course on ethics for software engineers (which is now open for pre-enrolment!) During my research for this course, I found an interesting – and scary – statistic.
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.
In recent years, some companies have tried to make their contracts easier to read. Why? The Consumer Protection Act defines the right to plain and understandable language in consumer contracts.