I’ve been sharing ideas on how to build security into your development process. An important step in the development process is testing.
There are many techniques used in security testing. It’s useful to understand the different approaches, and their advantages and disadvantages. Last week we looked at Static Application Security Testing (SAST). This week we look at DAST. (If you missed any of the previous articles, I’ve included all the links at the bottom.)
I’ve been sharing ideas on how to build security into your development process.
An important step in the development process is testing. There are many techniques used in security testing. It’s useful to understand the different approaches, and their advantages and disadvantages. So for the next few weeks we’ll look at the ways to test the security of your application.
From the previous post on decompiling, we saw how easy it was to recover source code from a compiled Java class file. There’s a lot of hard work and intellectual property embedded in those compiled files. What happens if someone gets access to your class files and decompiles everything? Your intellectual property is there for the taking!
You might have heard the expression “to go down the rabbit hole”.
It comes from the novel “Alice in Wonderland” written by Lewis Carroll in the 19th century. Alice falls down a rabbit hole, has quite a long trip, and lands in a strange place called Wonderland.
A rabbit hole can be a metaphor for something that transports you into a wonderful (or peculiar) place. But what we usually mean, is that we got extremely distracted. When we “go down the rabbit hole,” it means we spend a lot more time than we planned on something.
According to the UK IT Governance blog, 148 million records were breached in December 2020!
As stories of data breaches hit the news each day, many companies are trying to patch the security of their systems as quickly as possible.
That’s a start, but it’s not enough. Security is not a one-time task. It has to be built into your development process, not added on as an after-thought.
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.
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.
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