---
title: "AP Cybersecurity 5.5: Protecting Applications Exam Review"
description: "Learn secure by design, secure by default, and input sanitization for AP Cybersecurity. Covers how sanitizing user input stops SQL injection, XSS, and more."
canonical: "https://fiveable.me/ap-cybersecurity/unit-5/protecting-applications/study-guide/NlU1CUWEo8RNupZqXUMH"
type: "study-guide"
subject: "AP Cybersecurity"
unit: "Unit 5 – Securing Applications and Data"
lastUpdated: "2026-06-18"
---

# AP Cybersecurity 5.5: Protecting Applications Exam Review

## Summary

Learn secure by design, secure by default, and input sanitization for AP Cybersecurity. Covers how sanitizing user input stops SQL injection, XSS, and more.

## Guide

## TLDR
Protecting applications comes down to two ideas: secure by design and [input sanitization](/ap-cybersecurity/key-terms/input-sanitization "fv-autolink"). Secure by design means building security into a product from the first planning stage instead of patching it later, and it includes secure by default, where protections are turned on out of the box. Input sanitization means checking and cleaning what users type so attackers can't use control characters like the single quote, double quote, or semicolon to manipulate the system.

## Why This Matters for the AP Cybersecurity Exam

This topic builds your ability to think like both a defender and an attacker, which is the core skill the [AP Cybersecurity](/ap-cybersecurity "fv-autolink") course trains. You need to identify the application security principles of secure by design and secure by default, and you need to explain how input sanitization stops attacks. On exam questions, expect to connect a specific [mitigation](/ap-cybersecurity/unit-1/leveraging-ai-in-cyber-defense/study-guide/uvMQfHoviL6tgFrEstZ8 "fv-autolink") (sanitizing input) to the specific attacks it blocks, and to recognize when a product follows or ignores secure-by-design and secure-by-default principles. This connects directly to the unit's focus on how adversaries attack applications and how defenders limit or stop those attacks.

## Key Takeaways

- Secure by design treats security as a design principle in every phase of product development, not a feature added at the end.
- Secure by design has three principles: take ownership of customer security outcomes, embrace radical transparency and accountability, and build leadership and structure that support security.
- Secure by default means security features ship already enabled, so a product is safe out of the box.
- Control characters are the single quote ('), double quote ("), and semicolon (;), which applications use to wrap and process [user input](/ap-cybersecurity/unit-5/application-and-data-vulnerabilities-and-attacks/study-guide/T25I7qaDw4w4XT1rkAYr "fv-autolink").
- Input sanitization either strips out [malicious](/ap-cybersecurity/unit-3/detecting-network-attacks/study-guide/5kYH3dgJpqFp57SUnjEX "fv-autolink") characters or rejects bad input and forces the user to try again.
- Sanitizing input helps prevent [SQL injection](/ap-cybersecurity/key-terms/sql-injection "fv-autolink"), XSS ([cross-site scripting](/ap-cybersecurity/key-terms/cross-site-scripting)), and directory traversal attacks.

## 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 is that security is not just a technical feature you add later. It is a design principle that shapes the entire product from the beginning.

Compare this to the older way of building [software](/ap-cybersecurity/unit-4/protecting-devices/study-guide/n86HF5aR65a2DLQwNHDn "fv-autolink"). A company might rush to release a product, then [patch](/ap-cybersecurity/key-terms/patch "fv-autolink") security holes as attackers find them. Secure by design flips that order. Before code gets written, the team is already asking how the product could be attacked and how to prevent it.

### The Three Design Principles

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

1. **Take ownership of customer security outcomes.** Companies should build products that meet the security needs of their customers instead of pushing that responsibility onto users. If a product gets customers hacked, the company is responsible, not the user for "not configuring it right."

2. **Embrace radical transparency and accountability.** When a [vulnerability](/ap-cybersecurity/key-terms/vulnerability "fv-autolink") is found, a breach happens, or a patch is released, companies should share that news quickly and openly. Sharing relevant security information increases security for everyone, because others can learn from the same mistakes.

3. **Build organizational structure and leadership to support it.** Secure by design only works when leadership cares about it. That means having executives with a security-first posture and teams whose job is to build security into the product instead of patching it on later.

### Secure by Default

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 is why this matters. If a router ships with a default [password](/ap-cybersecurity/unit-1/suspicious-website-logins/study-guide/zppDvyHLHIUFzT3MNwAN "fv-autolink") of "admin" and [encryption](/ap-cybersecurity/key-terms/encryption "fv-autolink") turned off, most users will never change those settings. The device is capable of being secure, but in practice it is not. Secure by default means the device ships with protections already enabled, so users would have to actively weaken it to make it insecure instead of actively strengthening it.

A few examples of secure by default as an application of the concept:

- A new phone requires a passcode during setup instead of treating it as an optional add-on.
- An email service enables [HTTPS](/ap-cybersecurity/key-terms/https "fv-autolink") and spam filtering automatically.
- An operating system turns on its built-in [firewall](/ap-cybersecurity/key-terms/firewall "fv-autolink") by default.

The principle is simple: security should not be opt-in. Most users will not opt in, and attackers know that.

## User Input Sanitization

The second half of protecting applications is handling the reality that users, including attackers, type things into your app. Any time an application accepts input, 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 see 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 to know 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:

```sql
SELECT * FROM users WHERE username = 'yourname'
```

Those single quotes around `yourname` are control characters. They tell the database where the username starts and ends. That works fine for 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:

```
' OR 1=1; --
```

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

```sql
SELECT * FROM users WHERE username = '' OR 1=1; --'
```

The extra single quote closes the string early, so `OR 1=1` is now read as query logic, not as part of a username. Since `1=1` is always true, this query returns every user in the database. The attacker tricked the system into running their commands by sneaking control characters into the input. This is the basic idea behind a [SQL injection](/ap-cybersecurity/key-terms/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 removing or escaping 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 returns an error like "Invalid username."

A simple sanitization check in pseudocode might look like:

```
function sanitize(input):
    if input contains ' or " or ;:
        return error("Invalid characters")
    else:
        return input
```

Real-world sanitization is more advanced and often uses techniques like parameterized queries or escaping, but the core idea is the same: do not trust user input, and do not let control characters slip 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](/ap-cybersecurity/key-terms/cross-site-scripting "fv-autolink")) attacks.** Here, an attacker injects malicious script 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 example, an attacker might enter `../../etc/passwd` as a filename to try to read system files. Sanitization can strip these path sequences before they cause damage.

### Putting It Together

Secure by design and input sanitization work together. Secure by design is the big-picture mindset of thinking about security from the moment you start planning the product. Secure by default makes sure protections are on automatically. Input sanitization is one of the specific technical practices a secure-by-design team would build in from the start instead of patching after the first SQL injection attack hits the news.

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

## How to Use This on the AP Cybersecurity Exam

### MCQ

- When a question describes a product that ships with protections already enabled, match it to secure by default. When it describes building security into the planning and design phase, match it to secure by design.
- If a question lists a security failure where users were blamed for misconfiguration, connect it to the principle of taking ownership of customer security outcomes.
- Watch for the three control characters by name: single quote, double quote, and semicolon. A question may show input containing these and ask which mitigation applies.

### Connecting Mitigation to Attack

- Be ready to link input sanitization to the attacks it blocks: SQL injection, XSS, and [directory traversal](/ap-cybersecurity/key-terms/directory-traversal "fv-autolink").
- If a prompt shows a query string breaking early with an extra quote or `OR 1=1`, identify it as SQL injection and name sanitization (or rejecting input) as the fix.
- If a prompt shows `../` sequences in a filename, identify directory traversal.

### Common Trap

- Do not confuse secure by design with secure by default. Secure by design is the broad mindset across all development phases; secure by default is the specific idea that protections are on out of the box.
- Sanitization is not the same as encryption. Sanitization checks and cleans input; it does not scramble data.

## Common Misconceptions

- **Secure by design and secure by default are the same thing.** They are related but distinct. Secure by design is the overall approach of including security in every development phase. Secure by default is one piece of that approach, where security features are enabled out of the box.
- **Security can be added at the end.** Secure by design exists specifically because patching security on after release leaves gaps. Security is meant to be a design principle from the start.
- **Only obviously dangerous input is a [threat](/ap-cybersecurity/key-terms/threat "fv-autolink").** Any user input can be an attack vector. The safe assumption is that every input is suspicious until it is verified.
- **Sanitization always means deleting characters.** It can also mean rejecting the input and forcing the user to enter something valid, or escaping characters so they are treated as plain text.
- **Control characters are exotic symbols.** They are common characters you type all the time: the single quote, the double quote, and the semicolon. That is exactly why attackers use them.

## Related AP Cybersecurity Guides

- [5.1 Application and Data Vulnerabilities and Attacks](/ap-cybersecurity/unit-5/application-and-data-vulnerabilities-and-attacks/study-guide/T25I7qaDw4w4XT1rkAYr)
- [5.3 Protecting Stored Data with Cryptography](/ap-cybersecurity/unit-5/protecting-stored-data-with-cryptography/study-guide/pVI6SOT7HBVhSMIqKTXG)
- [5.2 Protecting Applications and Data: Managerial Controls and Access Controls](/ap-cybersecurity/unit-5/protecting-applications-and-data-managerial-controls-and-access-controls/study-guide/tZFME9LjYUHiIc9fHQE2)
- [5.4 Asymmetric Cryptography](/ap-cybersecurity/unit-5/asymmetric-cryptography/study-guide/VwtcdE1OgUXoQu0fiDG2)
- [5.6 Detecting Attacks on Data and Applications](/ap-cybersecurity/unit-5/detecting-attacks-on-data-and-applications/study-guide/sHDJEWboTNQbNsGPNiq5)

## Vocabulary

- **SQL injection attacks**: A type of application attack where malicious SQL code is inserted into user input fields to manipulate database queries and gain unauthorized access to data.
- **application security principles**: Foundational concepts and practices that guide the design and development of secure applications.
- **control characters**: Special characters such as single quotes, double quotes, and semicolons that encase user input during application processing and can be exploited for attacks.
- **cross-site scripting attacks**: Cross-site scripting attacks where malicious scripts are injected through user input to compromise web applications or steal user data.
- **directory traversal attacks**: An attack where an adversary uses path sequences like '../' in HTTP requests to navigate outside the intended directory and access unauthorized files on a server.
- **radical transparency**: A design principle where companies share relevant security-related product news and updates quickly to increase security for everyone.
- **secure by design**: An initiative that encourages companies to include security in all phases of product development, where security is treated as a design principle rather than just a technical feature.
- **security by default**: The concept that security features for software and devices should be enabled by default, allowing devices and software to be secure out of the box without requiring additional configuration.
- **security-first posture**: An organizational approach where security is prioritized as the primary focus in decision-making and leadership.
- **user input sanitization**: The process of verifying and cleaning user input to remove potentially malicious characters or code that could be used to manipulate an application.

## FAQs

### What is the difference between secure by design and secure by default in AP Cybersecurity?

Secure by design is the broad approach of building security into every phase of product development, treating it as a design principle rather than a feature added later. Secure by default is a specific part of that approach, meaning security features are already enabled when a product ships so users do not have to turn them on manually.

### What are the three principles of secure by design?

The three principles are: companies should take ownership of customer security outcomes, companies should embrace radical transparency and accountability by sharing security news quickly, and companies should build organizational structure and leadership that prioritizes security.

### What are control characters and why do they matter for application security?

Control characters are special characters that applications use to wrap and process user input; in AP Cybersecurity 5.5, the three to know are the single quote, the double quote, and the semicolon. Attackers can inject these characters into input fields to manipulate how the application processes data, which is why sanitizing them is a key defense.

### What attacks does input sanitization protect against in AP Cybersecurity?

Sanitizing user input helps protect applications against SQL injection attacks, XSS (cross-site scripting) attacks, and directory traversal attacks. A sanitization function either removes potentially malicious control characters from the input or rejects the input entirely and prompts the user to try again.

### How does a SQL injection attack work and how does sanitization stop it?

In a SQL injection attack, an attacker types control characters like a single quote into an input field to break out of the expected query structure and inject their own SQL commands, potentially accessing or manipulating a database. Input sanitization stops this by checking user input for control characters before the application processes it, either stripping them out or rejecting the input.

## Structured Data

```json
{"@context":"https://schema.org","@type":"FAQPage","inLanguage":"en","mainEntity":[{"@type":"Question","@id":"https://fiveable.me/ap-cybersecurity/unit-5/protecting-applications/study-guide/NlU1CUWEo8RNupZqXUMH#what-is-the-difference-between-secure-by-design-and-secure-by-default-in-ap-cybersecurity","name":"What is the difference between secure by design and secure by default in AP Cybersecurity?","acceptedAnswer":{"@type":"Answer","text":"Secure by design is the broad approach of building security into every phase of product development, treating it as a design principle rather than a feature added later. Secure by default is a specific part of that approach, meaning security features are already enabled when a product ships so users do not have to turn them on manually."}},{"@type":"Question","@id":"https://fiveable.me/ap-cybersecurity/unit-5/protecting-applications/study-guide/NlU1CUWEo8RNupZqXUMH#what-are-the-three-principles-of-secure-by-design","name":"What are the three principles of secure by design?","acceptedAnswer":{"@type":"Answer","text":"The three principles are: companies should take ownership of customer security outcomes, companies should embrace radical transparency and accountability by sharing security news quickly, and companies should build organizational structure and leadership that prioritizes security."}},{"@type":"Question","@id":"https://fiveable.me/ap-cybersecurity/unit-5/protecting-applications/study-guide/NlU1CUWEo8RNupZqXUMH#what-are-control-characters-and-why-do-they-matter-for-application-security","name":"What are control characters and why do they matter for application security?","acceptedAnswer":{"@type":"Answer","text":"Control characters are special characters that applications use to wrap and process user input; in AP Cybersecurity 5.5, the three to know are the single quote, the double quote, and the semicolon. Attackers can inject these characters into input fields to manipulate how the application processes data, which is why sanitizing them is a key defense."}},{"@type":"Question","@id":"https://fiveable.me/ap-cybersecurity/unit-5/protecting-applications/study-guide/NlU1CUWEo8RNupZqXUMH#what-attacks-does-input-sanitization-protect-against-in-ap-cybersecurity","name":"What attacks does input sanitization protect against in AP Cybersecurity?","acceptedAnswer":{"@type":"Answer","text":"Sanitizing user input helps protect applications against SQL injection attacks, XSS (cross-site scripting) attacks, and directory traversal attacks. A sanitization function either removes potentially malicious control characters from the input or rejects the input entirely and prompts the user to try again."}},{"@type":"Question","@id":"https://fiveable.me/ap-cybersecurity/unit-5/protecting-applications/study-guide/NlU1CUWEo8RNupZqXUMH#how-does-a-sql-injection-attack-work-and-how-does-sanitization-stop-it","name":"How does a SQL injection attack work and how does sanitization stop it?","acceptedAnswer":{"@type":"Answer","text":"In a SQL injection attack, an attacker types control characters like a single quote into an input field to break out of the expected query structure and inject their own SQL commands, potentially accessing or manipulating a database. Input sanitization stops this by checking user input for control characters before the application processes it, either stripping them out or rejecting the input."}}]}
```