A Guide to Application Security for Marketing Teams

“Security is a priority for this build.”

“Sure their stuff looks great, but is it safe?”

“Our data is confidential, and we need to make sure it stays that way.”

Chances are, you’ve heard (or said) one of these things in the last six months. You’ve also probably Googled something along the lines of “web app security”, or “cybersecurity”, or asked Mirah in IT about security, and then you’ve been hit in the face with a deluge of information, acronyms, and built-in-the-90s websites with a lot of words and tiny text. Faced with all this, how can you determine if a prospective web vendor will build a secure product?

Luckily, your Googling also turned up this blog post.

There’s a reason for all this information: security on the web is complex, and there are entire careers built on keeping the web safe. You definitely don’t need to become a security expert, but you will need to know a little bit about how your application functions in order to ask the right questions and do your due diligence. By the end of this article, you will:

• Have a general understanding of the structure and data storage needs for web applications and mobile applications
• Understand what your application needs to stay secure, in straightforward language
• Know how to assess vendors and identify those capable of executing that security on your behalf
• Be able to confidently assess and ask application security questions, with our free checklist and questionnaire download below.

An Overview

At its core, your application will have three main parts:

1. The device (often referred to as the front-end) is where a user interacts with your app by poking screens, clicking around, or typing on a keyboard. If we’re building an app that allows us to order pizza, this is the collection of buttons, images, and screens that you use to hunt down that perfect slice of pepperoni.
2. The server (also known as the back-end) is where most of the magic happens — this is where you would find your application’s files, data, and code. In our pizza app, this would be where we keep things like pricing information, store the actual images of pizza we need to send to the user’s device, and hold onto user account credentials… as well as deal with the logic of logging in and out, resetting passwords, and executing search queries for the one person that searches ‘anchovy.’
3. Any additional third-party integrations are bits of code that aren’t built by your vendor, but that your application makes use of. Maybe our pizza app uses Stripe to handle payments, or interfaces with an Uber Eats or Skip the Dishes API to organize delivery.

The Front End

In any application, user interaction is required… after all, what good is a pizza app if you can’t search for different kinds of pizza? The challenge with user input from a security standpoint is that we often use user input to change the state of the application. If I ask for pepperoni pizza, show me pepperoni! If I ask for ham-and-pineapple, show me ham-and-pineapple! This is great when the user inputs are expected, but what happens when someone tries to submit unexpected inputs?

This is the premise behind two of the biggest threats to the front-end of your application: SQL injection, and DDoS. Those terms aren’t exactly the clearest in terms of what they mean to you though (or why you should care about them), so let’s talk about pizza orders.

Our pizza shop is bustling in the pre-app world, and so we implement an ‘order form’ system. You can step up to the counter, fill out a little slip of paper with what you want on your pizza, and hand it to the cashier— who will then charge you $15 per slip of paper, take what you’ve put on your order form, and turn it into a pizza for you. At a really high level, we can think of this as the front-end of an application; the cashier takes inputs (your slip of paper plus $15) and turns it into something of value to you (your pizza). Some expected inputs would be things like handing the cashier a slip that says ‘vegetarian’, or ‘half-pepperoni, half-cheese’.

How can we game the system at our pizza place? Well, you could write really small, and squeeze something like “pepperoni pizza and two more pepperoni pizzas” onto a single slip. Since we’re being charged per-slip, this isn’t ideal for the pizza shop. You could also do something like show up with 10,000 pre-filled papers that say “pepperoni pizza.” Nothing wrong with the requests individually, but now the poor cashier needs to read through all those papers and can’t get to anyone else today.

Similar problems will exist for our application: in the world of computer security, those two attacks are called ‘SQL injection’ (convincing the server to do something other than what was intended… like supplying additional pizzas) and ‘DDoS’ (overwhelming a server with a flood of legitimate requests) attacks. If your application doesn’t address these issues, you’ll be left with either an application unable to respond to incoming requests, just like the overwhelmed cashier, or the potential to expose unintended data. What if instead of two more pizzas, I had wished for the usernames of all the users in our app? Or wished for the entire database to be deleted? Following industry-standard practices in rate-limiting and ‘prepared’ database queries – think a ‘check-box’ order form, where you have to check off toppings instead of writing anything you want on the paper– will ensure your data remains accessible, un-modified, and un-exposed.

The Back End

Most legitimate interactions with your app will be via the front-end, but that’s not the only way that your data can be accessed. The back-end of our application needs to be locked down as well, and there are three main functions we need to secure:

1. Direct access to the back-end itself. We don’t want anyone able to access the server (or execute code on the server) that shouldn’t be there.
2. Access to particular files. Some files (like images of delicious pizza) can be exposed to the public safely, while others will need to stay inaccessible (like a secret pizza recipe).
3. Direct access to the database. Often critical data is stored here (like usernames and passwords), and we don’t want anyone to be viewing those.

Since we’ve secured requests coming from the front-end of the application, we need to worry about requests coming to the server through other means. Some of those will be perfectly normal (we often access servers to create backups, update systems, or perform routine checkups)… and some may be malicious.

The primary line of defence for the back-end of an application will always be limiting access. There are several ways to do this: at minimum, you should be requiring a username and password to access the server. Additionally, we can restrict access to only allow connections from a particular computer (or set of computers), require additional passwords, or limit connections to those coming from a set of networks.

Let’s say a thief is trying to break into our castle to steal our top-secret pizza recipe. This layer is a guard; not just at the front gate, but at the doorway to every system in our server, doing our best to ensure that any sort of traffic passes inspection before it sets foot inside our server. Much like guards however, this imposes a tradeoff for our application. The heightened security comes at the cost of convenience for our users, and a responsible software development team will work with you to determine the appropriate level of security for your application.

The second layer of back-end security is for anyone that somehow makes it past the guard: obfuscation. In the unlikely scenario that our thief makes their way into the castle, we can further confuse them by making sure all the rooms have unexpected names; why name the treasure room ‘treasure room’? That way, if a thief goes looking for the ‘treasure room’, they won’t be able to find it. Similarly, we can name our folders, usernames, and databases uncommon things to prevent them from being guessed easily.

Our final layer of back-end security is encryption. Our thief has passed all the guards, puzzled out that the treasure room is really called ‘the kitchen’, and finally found our secret recipe, they unfurl it to discover:

They can’t read it. Encryption is the process of scrambling regular words and numbers into something unintelligible, and is a powerful tool… although not all encryption is created equal. As with our guards, it comes with tradeoffs, this time between security and performance. Encrypting data certainly makes it secure – without the key, the current industry standard encryption (AES-256) would take on the scale of millions of years to crack – but accessing encoded data requires your application to consume more resources (or, conversely, your application will access data slower if it is encrypted). A responsible software development firm will work with you to determine what needs to be encrypted, and what data isn’t necessary to protect to the same degree. For example, your user’s logins certainly require encryption, but our application’s ‘pizza topping’ categories likely don’t require the same treatment.

Of course, all these layers of protection are supremely helpful, but one final piece remains to round out responsible back-end security: monitoring. Much like the dragon keeping an eye on the treasure-room (err… ‘kitchen’), monitoring the actions and resource usage of your application can identify potential threats – and neutralize them – before they become realized. Regular scans for vulnerabilities and real-time application monitoring are invaluable tools to keep your application – and your pizza recipes – secure.

Third Party Integrations

Your future application development partner is focused on delivering value for you and your organization. While often that involves writing custom code, sometimes that also means not re-inventing the wheel. Third-party code can be found throughout most any system, from the operating system your server runs on, to the Uber Eats integration that handles delivery for our pizza application. No matter which vendor you ultimately partner with for your mobile or web application, they will rely on third party code to some degree.

Because this code is found throughout the system, all of the above points apply to it. Your application developer will rely on the developers of that code to have handled security in a responsible manner. It is critical that your development team recognizes this, and:

1. Vets potential third-party additions to the system for security, performance, and relevance
2. Monitors them for any newly-discovered vulnerabilities
3. Updates or patches code to ensure up-to-date protections are in place.

Go Forth & Be Secure – Figuratively & Literally

Your data (and your application) matter to you. If they didn’t, you wouldn’t have opened this article, and you certainly wouldn’t have gotten this far. Understanding which areas of your application require security is critical to being able to ask smart, relevant questions… and to use them to identify vendors that know their stuff from vendors that pay lip service to security.

Identifying a partner who will also ask the right questions of you is equally important. A web app for government engagement, a nation-wide tool for school zone safety, and an application ecosystem for safety compliance will all have very different balances to strike in terms of security, ease-of-use, and performance. We’ve struck this balance countless times, and continue to do so with every project that leaves our door. It’s why we’re trusted to execute by national level clients like the Canadian Automotive Association and the Edmonton International Airport, and why we’d be a great fit for you as well: we don’t just take your security requests and stop there, we approach security with the same collaborative spirit that drives everything we do. The security of your application and your data is a team effort – and now that you know more about how your application will communicate and store data, choosing your team is a little bit easier.