Application security is seldom considered during the ideation phase of web application development - unless the development team has previously been hacked and survived to tell the tale. But it's also true that it's never too late to secure your cloud-based web app.
In fact, smart and fast-growing cloud software companies who outperform their peers usually share this common trait: they consistently grow sales and build their brand by turning their security standards into a key differentiator and selling point.
There are at least three things that these smart companies do to prove to their B2B customers that their web application is secure and can be trusted. How many of these three things do you offer your prospective customers?
Why is cloud application security important?
Great question. There are the most obvious and often quoted reasons for investing in robust application security standards and processes:- It helps to protect your business.
- It helps to protect your customers' business.
- It helps to minimise your costs when you do eventually get hacked.
- Prevention is always better than cure.
- As a professional, it's your moral (and legal, in many countries) obligation to ensure that the solution you provide to your customers is as secure as possible.
However, you will most likely view this finding from an IBM Security study to be the most compelling data point when deciding if now is a good time to look at your web application's security standards:
Doesn't it then make complete sense to give your potential customers just what they're looking for? Combine the above overarching statistic with these 10 cybersecurity questions that enterprise clients consider when evaluating cloud service providers, you'll quickly realise that you've found the illuminated runway that leads to your cloud sales goals.
What are web application security controls?
Web application security controls are the building blocks for creating a secure web application. They are measures that are tested with security audits and are essentially security measures that protect your app's users from falling victim to sensitive data loss.
A secure web application is one that has an adequate level of controls in place to protect the confidentiality, integrity and availability of the web application and its data.
The most secure web applications use best practice security features throughout the software development lifecycle.
Contrary to what you might have heard, modern security controls for web applications require you to invest in a combination of tools, best practices, training and security tests that can sometimes be performed in-house, but are generally conducted by experienced penetration testers to uncover security vulnerabilities.
Are security controls different for web applications hosted on-premise vs in the cloud?
Not really. A cloud server, like an AWS EC2 instance, is still a server. The only difference is that it is sitting in AWS' datacentres, rather than in your office.
Everything that you read here is relevant to you whether you host your own web applications or use a cloud platform like AWS.
Just be aware (as you'll read below) that hosting your application on the cloud doesn't absovle you of the responsibility to protect your infrastucture!
How to secure web applications?
The most common answer you might hear is that all you need to do to secure a web app is to get a web application penetration test done.
Some more knowledgeable people might also advise you to invest in cybersecurity training for your development team. Frankly, combined, these are reasonable suggestions.
But in this day and age where your team is shipping new versions of your app on an almost daily basis, these two things along are simply not enough.
There is no finish line in application security. You need to keep running & do as many miles as your time & budget will allow you.
Penetration testing for web applications is one piece of the puzzle that is your overall application security posture. Pen testing is a big part of that puzzle, but it's only useful when it's performed with the right structure.
What do I mean? Consider this: when a nation's armed forces are trying to rid a city of terrorists, they don't just go in with the army, do they? They first call for drone surveillance, then the air force for targeted strikes, then advanced reconnaissance units are sent it, followed by heavy infantry and more soldiers. All of this is then supported by engineers and civilian support to rebuild that city.
Simply engaging a vendor to conduct an annual penetration testing service on your cloud application and nothing else is like sending battalions into a war zone without any idea of where the enemy is hiding.
By conducting penetration tests alone, you will be wasting your money and diminishing your ROI.
A web application penetration test should be:
- Preceded by meaningful web app security testing during the design phase (share this web application security best practices PDF with your development team to help them understand the security mechanisms that they should build into new and existing features in your cloud application).
- Backed by automated web app vulnerability testing of your code base to check for compromised code.
- Supported by regular static code scanning of your entire code-base, every commit.
- Fortified by authenticated automated vulnerability assessments of our web app and its infrastructure before you go live.
- Reinforced with regular drills (ie. cybersecurity training) to help your team understand what they need to do in the event of an attack.
Four of the five steps above can be easily implemented by talking to a pentesting-as-a-service solution provider. Because PTaaS is literally a turnkey way to help you implement the structure above.
I'm not telling you cybersecurity is easy. I’m telling you that it is doable. I’m telling you that the first step is the hardest. Your team is unlikely to take the first step until you lead the way by showing them what to do.
Want my team to show you how to put a scaleable web application security structure in place?
But my web app is hosted on AWS/Azure/Google Cloud and they look after my security
You’re not completely wrong, because to an extent these hosting platforms do provide a level of security. But it’s a very minimal security layer that they offer (unless you have the budget to pay for their really effective security offerings).
These massive cloud hosting platforms typically offer protections against large-scale DDOS attacks and the like.
The flexibility and sheer range of services offered by cloud platforms like AWS and GCP and Azure present their own unique security challenges. Securing them is a very different exercise to securing your web application or mobile application.
This is why we offer a cloud platform cybersecurity testing services that allow you to implement the right security controls. There are over 200 security controls that we look for but the most common ones include:
- Configuring IAM settings in the most secure way.
- Configuring secure communications between various servies that you're using.
- Setting up automated alerts and monitoring to understand when there's an issue.
- Creating end-to-end encryption of your services and pipelines to secure your code and data.
- Setting up self-remediation where possible.
Such protections are almost useless if your developers often open random ports into your environments. Or if they don’t close SQL injection vulnerabilities that allows an attacker to download your entire database without any valid login credentials. Or if they forget to apply security patches for the open source libraries that your cloud application uses.
The vulnerabilities leave you and your web applications wide open to a myriad of attack vectors. Only a deliberate and methodical application security structure like the one described above will help your developers find and fix these security vulnerabilities before it’s too late.
What are the web application security basics to implement?
Contrary to popular belief, application security or SaaS security does not have to be an expensive, time-consuming and an anxiety-inducing exercise.
The good news for you is that simply implementing the basics of web application security will also set you on the path to follow web application security best practices.
In fact, properly configuring your web app’s first line of defence against attackers should be a reasonably quick exercise for most competent developers.
The first step to making it difficult for hackers to hack your web app or exploit it for other nefarious motives, is to configure 7 security-focused HTTP headers.
These HTTP headers tell the browser how users can interact with your application and infrastructure.
More, importantly, these security headers instruct browsers about what users SHOULD not be able to do when loading and interacting with your application.
The good news is that there are really only seven security-focused HTTP headers that your developers need to configure. Here’s a quick rundown of what the seven HTTP security headers that your web application needs:
- X-Frame-Options - helps you combat clickjacking attacks by controlling whether browsers can render your web app in frames.
- Strict-Transport-Security - strengthens your app’s ability to enforce TLS encryption of data in transit by forcing the use of the secure HTTPS protocol.
- X-Content-Type-Options - helps to counter MIME Confusion attacks and unauthorised hotlinking attacks.
- Feature-Policy - allows you to selectively enable, disable, and modify the behaviour of APIs and features in the browser.
- Set-Cookie - implementing the right directives makes it difficult for hackers to exploit cross-site scripting (XSS) vulnerabilities and hijack the authenticated user sessions.
- Referrer-Policy - helps you control if and how much information your application submits to external websites that your users are clicking through to.
- Content-Security-Policy - allows you to explicitly define the sources from which a browser can load components when rendering your application. It supersedes previously recommended headers like X-WebKit-CSP and X-Content-Security-Policy.
Want a quick security vulnerability assessment report to see the application security controls you're missing?
What's the easiest & quickest way I can check my HTTP security headers?
You want easy AND quick? You don't ask for much do you! ;-PThe easiest and quickest way to check how many of these seven HTTP headers your web application uses adequately is by using the CyberChief.ai HTTP header analysis service. Simply enter your web app’s login page and in less than 2 seconds you will be will have a complete analysis of the HTTP headers that are already configured properly, and those that need more work.
The best part is that Cyber Chief’s recommendations spell out in detail where your developers can configure these HTTP headers in your application. It will also explain what directives and keywords should be used maximise the security that each HTTP header can offer.
At this stage, it would be remiss of me to not point out that this header optimisation process is pointless unless you are serving your web application over HTTPS and ensuring that all HTTP traffic is automatically redirected to the more secure HTTPS protocol.
There are usually zero compelling reasons to pay hundreds or even thousands of dollars fancy SSL certificates from brand-name SSL certificate vendors. A free SSL certificate from services like LetsEncrypt or Cloudflare will be more than adequate for most cloud applications.
Remember that this HTTP header configuration process is only the first step in your journey to securing your web application and its infrastructure. The speed at which you’re able to build the remaining structure will determine a) how far ahead of attackers you can get, and b) how quickly you can turn your new cybersecurity resilience into a selling point to grow sales convert faster.
Download our application security controls checklist to understand the minimum security controls your SaaS application must have. It could just save your product and your company from much embarrassment and even the loss of you and your team's livelihood.
It probably will also help you land your next (or first) big enterprise customer for your SaaS.
Are there additional best practice security controls suggested by OWASP?
OWASP indeed has a very rigorous list of best practice application security controls, you can access them here.
TL;DR, OWASP's list includes specific controls as well as 11 more general web app security best practices like these:
- Patch your systems regularly
- Implement a Web Application Firewall (WAF)
- Use an automated web app security testing tool to look for security weaknesses
- Perform input validation on all inputs
- Sanitize the output of error messages
- Separate development or non-production environments from production environments
- Perform manual and automated secure code analysis (see below about SAST tools)
- Verify vendor security processes
- Secure your databases with adequate security hardening
- Train developers on writing secure code
- Remove development artifacts from production code
OWASP is undoubdtedly a great source to level up your coding practices to minimise security threats and protect sensitive data.
We can't do everything at once, but we can do something at once.
However, keep in mind that it's not always possible to implemenet to all OWASP security controls and the myriad others that you will hear about, like:
- Multi-factor authentication
- Salting and hashing
- CORS protections
- Access controls hardening
- Source code sanitization
- Etc, etc, etc...
Your biggest conundrum is that the security controls you choose not to implemement might be the one that causes the application layer data breach you wanted to prevent!
That's why my tean gives you application security discovery calls, because they can help you understand the different trade-offs you might need to make and how to stay secure despite not being able to protect against every attack vector.
How can I test my web application security controls?
The DIY method of testing your web application security controls is by using good vulnerability scanners. Web application security scanners are tools that can scan websites and applications and issue alerts when the application is vulnerable to a particular type of attack.
There are many types of scanners, which all work differently, so, choose one that's right for your needs. The two types of web application security tools that you must have are:
- Static code scanning (SAST): static scanners integrate with your GIT repository and scan your codebase line-by-line to see if known vulnerable code eixsts.
- Dynamic application security scanning (DAST): automated penetration tools for web apps like Cyber Chief look at your application after it's been compiled to find vulnerabilities like XSS, remote code injection vulenrabilities, access control vulnerabilities, inpult validation vulnerabilities, SQL injections and other nasty OWASP Top 10 vulnerabilities.
The second non-DIY way of validating your web app security controls is by asking a penetration testing firm to perform a web application penetration test.
A penetration test is where you let a team of highly trained and certified penetration testers go to work for you. Previous experience working in-house for your industry will enable them to quickly move from scanning to assessing, and then to exploiting vulnerabilities so that they can validate the effectiveness of your app's security controls.
This type of security audit will help you assess the ways the app and backend systems are vulnerable to attack and how that can lead to a break in.
As you can see, software security today is not as easy as it once was. You need multiple layers of security features, each addressing different best practice areas of web application security controls.
If you need to understand the right application security testing structure that would work for your team, why not book a discovery call where my team can take you through the structure that's right for you?
