5.5 Protecting Applications

Applications are everywhere. The apps on your phone, the websites you log into, the software that runs your school's grading system. Each one is a potential target for attackers, which means developers can't just bolt security on at the end and hope for the best. Protecting applications starts with how they're built and how they handle the data users type in. This topic covers two big ideas: building security in from the start (secure by design) and making sure user input can't be used as a weapon.

Secure by Design

Secure by design is an initiative that pushes companies to include security in every phase of product development, starting with the design phase. The key idea: security isn't just a technical feature you add later. It's a design principle that shapes the entire product from day one.

Think about how this differs from the old way of building software. Traditionally, a company might rush to release a product, then patch security holes as hackers find them. Secure by design flips that. Before a single line of code gets written, the team is already asking, "How could this be attacked? How do we prevent that?"

more resources to help you study

practice questions

The Three Design Principles

Secure by design rests on three principles that companies are expected to follow:

1. Take ownership of customer security outcomes. Companies should build products that actually meet the security needs of their customers, not just push the responsibility onto users. If your product gets your customers hacked, that's on you, not on them for "not configuring it right."

2. Embrace radical transparency and accountability. When something goes wrong (a vulnerability is found, a breach happens, a patch is released), companies should share that news quickly and openly. Sharing relevant security information helps everyone, because other companies can learn from the same mistakes and protect their own users.

3. Build organizational structure and leadership to support it. Secure by design only works if leadership actually cares about it. That means having executives with a security-first posture and building teams whose job is to bake security into the product, not patch it on later.

Secure by Default

Sitting inside secure by design is a related concept: secure by default. This is the idea that security features should be turned on out of the box, with no extra work from the user.

Here's why this matters. If a router ships with a default password of "admin" and Wi-Fi encryption turned off, most users will never change those settings. The device is technically capable of being secure, but in practice it isn't. Secure by default means the router would ship with a unique, strong password and encryption already enabled. Users would have to actively weaken the device to make it insecure, instead of having to actively strengthen it.

Other examples of secure by default in action:

• A new iPhone requires a passcode during setup, not as an optional add-on.
• Gmail enables HTTPS and spam filtering automatically.
• Windows turns on its built-in firewall the moment you boot up.

The principle is simple: security shouldn't be opt-in. Most users won't opt in, and attackers know that.

User Input Sanitization

The second half of protecting applications is dealing with the messy reality that users (and attackers) type things into your app. Any time an application accepts input from a user, that input becomes a potential attack vector. User input sanitization is the process of checking and cleaning that input before the application acts on it.

To understand why this matters, you need to understand control characters.

Control Characters

When an application processes user input, it usually wraps that input in special characters so the system knows where the input starts and ends. These special characters are called control characters. The three most common ones are:

• The single quote: '
• The double quote: "
• The semicolon: ;

For example, if you type your username into a login form, the application might wrap it in quotes when it builds a database query, like this:

</>SQL
SELECT * FROM users WHERE username = 'yourname'

Those single quotes around yourname are control characters. They tell the database, "the username starts here and ends here." That's fine when users type normal input. The problem is what happens when an attacker types control characters into the input itself.

How Attackers Abuse Control Characters

Imagine an attacker types this into the username field:

</>Code
' OR 1=1; --

If the application just shoves that into the query without checking, you get:

</>SQL
SELECT * FROM users WHERE username = '' OR 1=1; --'

That extra single quote closes the string early, and now OR 1=1 is being read as part of the query logic, not as part of a username. Since 1=1 is always true, this query returns every user in the database. The attacker has tricked the system into running their commands by sneaking control characters into the input. This is the basic idea behind a SQL injection attack.

What Sanitization Does

To stop this, programmers should use a function that checks user input before the application processes it. This verification function does one of two things:

• Sanitize the input by stripping out or escaping any potentially malicious characters (like control characters), or
• Reject the input entirely and force the user to try again with valid input.

For example, if a username field should only contain letters and numbers, the sanitization function can check for that. If someone types ' OR 1=1; --, the function either removes the dangerous characters or kicks back an error message like "Invalid username."

A simple sanitization check in pseudocode might look like:

</>Code
function sanitize(input):
    if input contains ' or " or ;:
        return error("Invalid characters")
    else:
        return input

Real-world sanitization is more sophisticated (it often uses techniques like parameterized queries or escaping), but the core idea is the same: don't trust user input, and don't let control characters sneak through.

Attacks That Sanitization Helps Prevent

Sanitizing user input protects against several common application attacks:

• SQL injection attacks. As shown above, these inject SQL control characters and commands into input fields to manipulate a database. An attacker can steal data, delete tables, or bypass logins.
• XSS (cross-site scripting) attacks. Here, an attacker injects malicious JavaScript into a website's input field (like a comment box). When other users load the page, their browsers run the attacker's script. This can steal cookies, hijack sessions, or redirect users to malicious sites. Sanitizing input that gets displayed back to users blocks this.
• Directory traversal attacks. These use control characters and path sequences (like ../) to trick an application into accessing files outside the intended folder. For instance, an attacker might enter ../../etc/passwd as a filename to try to read system files. Sanitization can strip out these path sequences before they cause damage.

Putting It Together

Secure by design and input sanitization work hand in hand. Secure by design is the big-picture mindset: think about security from the moment you start drawing up the product. Secure by default makes sure protections are on automatically. Input sanitization is one of the specific technical practices that a secure-by-design team would build into their app from the start, not patch in after the first SQL injection attack hits the news.

The bottom line: applications fail when developers assume users will only type what they're "supposed to" type. Good application security assumes the opposite. Every input is suspicious until it's verified, and every product ships secure unless the user changes something.