Security For Your Web Apps - And Why It's Important
Tags: webdev, security
Published: 2019-03-10 09:46:42

---
title: Security For Your Web Apps - And Why It's Important
published: true
description: A quick and dirty look at some of the ways that your site can be hacked, and why you should care
tags: webdev, security
cover_image: https://images.unsplash.com/photo-1527412470402-714663147471?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=1350&q=80
---

Your company's web applications are the gateway for your customers.

Gone are the days when someone would browse through Amazon, pick an item, call Jeff Bezos directly, give him their credit card details over the phone, and expect their product within 2-4 weeks. Almost everything is done online.

Almost none of your customers will travel to your head office; very few (if any) will ever call your publicly listed phone number; a handful of them will make it as far as emailing you; a small percentage of them will use an online-chat system (if you provide one); but _all_ of your customers will use your web applications.

### Hackers Abound

I personally don't like to use the phrase `hackers`, but that's because I prefer the old meaning of the term:

> Someone who doesn't use engineering processes when creating code. They "hack around in the code base, removing code blindly, trying to make it work"

But if the shoe fits...

Sure, a lot of hackers these days will launch complicated attacks against your servers - and that's still a legitimate concern. But with services like Azure, AWS, and GCP, it's getting harder for malicious folks to break into your infrastructure.

###### NOTE

My previous statement assumes that the infrastructure is set up with security best practises in mind. i.e. no VMs (WebApps or serverless architecture), service principals rather than usernames and passwords, multi-factor authentication, applying the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege)

---

There have always been attacks against the client (in this case the Browser), but they are slowly becoming more prevalent. A lot of folks get started in this arena by utilising [Google dorking](https://en.wikipedia.org/wiki/Google_hacking) techniques, they then move on to the techniques used by [Script Kiddies](https://en.wikipedia.org/wiki/Script_kiddie). These are simple techniques that you can just copy and paste without having to understand what they do.

In fact, it's so easy to do that Troy Hunt had his (then) [3 year old son perform a SQL injection attack](https://www.troyhunt.com/hacking-is-childs-play-sql-injection/), on camera.

These techniques can be pared up with the results of a quick search on [Shodan](https://www.shodan.io/) to launch attacks on vulnerable systems.

##### Pro tip:

Have someone within your organisation do frequent searches on Shodan to ensure that you haven't opened any potential gateways into your applications or infrastructure.

If you don't, someone malicious will.

---

### Security As a Feature

Oh so frequently, we (at RJJ) have seen that security is thrown in as a last minute feature. This can be, and is often, disastrous.

We've seen cases of applications where security is added as an afterthought, yet breaking into the system was child's play (see my earlier comment about how easy it is do use Script Kiddie techniques).

This leads to security teams becoming the nemeses of development teams. But, just as with Dev and Ops, we all need to be working together to ensure that the applications we built are secure from the off. For allegorical proof of this, I'd recommend reading [The Phoenix Project](https://www.goodreads.com/book/show/17255186-the-phoenix-project).

The most secure applications - just like the most secure buildings - have security baked into their designs from the very beginning. This allows us to include security checks as part of our automated test suite.

_you ARE using automated testing, right?_

This ensures that no one is able to release a "quick fix, will improve security later" (that's an actual commit message that I've seen in the past, by the way), because it won't get past the automated tests.

But doing this is hard. Which is why "DevSecOps" is now a legitimate career path for folks who want to increase the security of applications. The problem is that there's so much to learn, and almost no time to learn it, right?

### Free Tools

I've [written about OWASP before](https://dev.to/dotnetcoreblog/owasp---who-jck). In their own words:

> The Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. Our mission is to make software security visible, so that individuals and organizations are able to make informed decisions. OWASP is in a unique position to provide impartial, practical information about AppSec to individuals, corporations, universities, government agencies, and other organizations worldwide. Operating as a community of like-minded professionals, OWASP issues software tools and knowledge-based documentation on application security

Everything that they do (aside from conferences like Global Appsec) is free. Free training materials, [free meetups](https://www.owasp.org/index.php/OWASP_Chapter), free software tools, free knowledge sharing.

_by "free" I mean "free as in beer, a.k.a: no remuneration required_

Not just that, there are conferences and meetups all about application security. There are courses you can take, and there are books that you can buy. You can even try to become a l33t hax0r yourself by using things like [Kali Linux](https://www.kali.org/)

_Kali is a distribution of a Linux based operating system which is designed for penetration testers and white-hat hackers_

The problem is that learning how to beat the malicious folks requires a _tonne_ of learning. Sure, it's all free information, but there's a lot of it and it can take a lot of effort to learn it. But you can learn it piecemeal.

### You Company's Applications ARE Its Reputation

Imagine if Amazon suffered a _massive_ security breach. Like, lets say that all of orders for a 6 month period for all of their customers were leaked. We're talking names, addresses, credit card numbers, order line items (the stuff that people ordered), everything.

_I'm not saying this has happened, I'm just trying to craft an example_

Aside from the initial fallout of everyone's data being available to malicious people, and the potential embarrassment some people might have about their shopping habits become public knowledge

_seriously, have you ever bought something that would be difficult to explain to a loved one, let alone a friend, stranger, or even your employer?_

Aside from all of that, Amazon's reputation would be trashed. They would be dragged through the mud by the media and would have to work exceptionally hard to spin the story in their favour.

Not only that, AWS is an Amazon product. There are millions (if not billions) of people who rely on AWS on a daily basis - even if they don't know it. If Amazon was breached, AWS would be next. Companies like Capital One, BP, GE, Time, and Philips would be hit. Not to mention AWS's killer app: Netflix.

Imagine if your company was successfully attacked, and all of your customer data stolen. Would it survive the PR nightmare?

And that doesn't even touch on things like [GDPR](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation), and other sets of regulations that you need to abide by. Imagine if your company had to defend itself against against a GDPR strike. There's no coming back from that, no matter how good your products are services are. You customers would leave.

That's why application security is so important to your company. At least, from a business owner's perspective.