Protecting Applications
The best time to secure an app is before it ships. Run the launch security review and learn to build apps that are secure by design and safe by default.
Welcome to the AgriNova Application Launch Review. The team is about to release a new customer ordering app. Before it goes live, you'll review it for two foundational principles — secure by design and security by default — and confirm it properly handles the most dangerous thing any app touches: user input.
Secure by design means security is built into the app from the very start, not bolted on later. Security by default means the app ships with its safest settings already turned on. Together with input sanitization, they shrink the application's attack surface before an attacker ever gets a chance.
Secure by Design
Bake security into the app from the first design decision — not as a patch after launch.
Security by Default
Ship with the safest settings on so users are protected without extra steps.
Sanitize Input
Validate and clean user input so malicious data can't change how the app behaves.
- 1Identify secure by design and security by default.
- 2Explain how user input sanitization protects applications.
AgriNova's new ordering app is feature-complete but unreviewed: its search box passes input straight through, debug mode is on by default, accounts start with broad permissions, and error messages leak internal details. You'll run the launch review — checking secure-by-design practices, flipping settings to secure defaults, and testing input sanitization — all on a safe, fictional app.
Big Idea
Secure software is designed to be safe and defaults to safe — so users don't have to be security experts. And because user input is the #1 way apps get attacked, sanitizing input is one of the highest-impact protections you can build in.
You'll identify secure-by-design and security-by-default practices, explain how input validation and sanitization protect applications, and harden a launching app to reduce its attack surface — the AP Mitigate Risk skill applied to software.
Design Safe, Default Safe, Sanitize Input
Three building blocks of application protection — and how they reduce attack surface.
Application protection rests on three ideas:
- Secure by design: security is considered at every stage of building the app — planning, coding, testing — so weaknesses are prevented rather than patched.
- Security by default: the out-of-the-box configuration is the safest one (e.g., least privilege, strong settings on, debug off). Users get protection without extra effort.
- Input validation & sanitization: validation checks that input is the expected type/format; sanitization cleans or neutralizes dangerous characters so input can't be used to attack the app.
The shared goal is reducing the application attack surface — fewer unsafe behaviors, fewer risky default settings, fewer ways for malicious input to do harm.
' OR '1'='1 is treated as harmless text, not as a command — so it can't alter a database query or inject a script. Sanitizing turns potentially dangerous input into plain data, removing a whole class of application attacks.
Secure-by-Design Checklist
Work through the secure-by-design practices the team should have followed while building the app. Your readiness meter fills as you complete them.
- Consider threats during the design phase (threat modeling)
- Apply least privilege to accounts and components
- Validate & sanitize all user input by design
- Minimize features/attack surface (only what's needed)
- Show safe error messages (no internal details leaked)
- Security-review the code before launch
Terms for MCQ and Application Security Analysis
Definitions you'll need for multiple choice and free-response answers.
| Term | Definition | Launch-Review Example |
|---|---|---|
| Secure by design | Security built into the app from the start of development. | Threat modeling during planning. |
| Security by default | The app ships with its safest settings already enabled. | Debug mode off by default. |
| Secure defaults | The safe out-of-the-box configuration values. | New accounts get least privilege. |
| Input validation | Checking input is the expected type/format before use. | Order ID must be a number. |
| Input sanitization | Cleaning/neutralizing dangerous characters in input. | Escaping special characters. |
| Unsafe input | User input that could change app behavior if trusted. | Script or command in a text box. |
| Attack surface | All the points where an app could be attacked. | Every input field & feature. |
| Least privilege | Giving only the minimum access needed. | Users can't reach admin tools. |
| Defense in depth | Multiple layers of protection working together. | Design + defaults + sanitizing. |
| Input Validation | Input Sanitization | |
|---|---|---|
| Question it asks | "Is this input allowed?" | "Can I make this input safe?" |
| Action | Accept or reject | Clean / neutralize dangerous parts |
| Example | Reject letters in a phone field | Escape < & ' characters |
| Together | Validate first, then sanitize — layered protection for every input. | |
What the Exam Wants You to Explain
Skill in focus: Mitigate Risk — protect the app with design, defaults, and input handling.
For protecting applications, AP expects you to: (1) identify whether a practice is secure by design or security by default, and (2) explain how input sanitization mitigates risk — by neutralizing dangerous input so it's treated as plain data and can't change the app's behavior, reducing the attack surface.
- Confusing secure by design (built in from the start) with security by default (safe settings out of the box).
- Treating validation and sanitization as identical — one accepts/rejects, the other cleans.
- Thinking client-side checks alone are enough — input must be handled where the app trusts it.
- Assuming a feature-rich app is safer — more features usually means more attack surface.
If a stem says "debug mode was left on when the app shipped," that violates security by default. If it says "the search box passes input straight into a query," the fix is input validation + sanitization — explain that cleaning the input stops it from changing the app's behavior.
input handling:
search box NOT sanitizeddefault config:
debug = ON, new users = adminerror pages:
leak stack tracesfeatures enabled:
all (incl. unused legacy import)
Read it like AP wants: unsanitized input = missing input sanitization (mitigate by validating/cleaning); debug on + admin-by-default = broken security by default (ship safe defaults); leaked stack traces & unused features = unnecessary attack surface a secure-by-design review would have caught.
Lab: Input Sanitization Simulator
The flagship lab. Feed input to the ordering app and watch sanitization neutralize the dangerous parts, then read the AP-style reasoning.
Sanitization is the single highest-impact application protection. Type input below and toggle sanitization on/off to see the difference between what an unprotected app would trust and what a sanitized app stores as harmless data. (Special characters are shown neutralized for illustration — no code is executed.)
Security-by-Default Toggle Lab
Flip each setting to its secure default. Your default-safety score rises as the app ships safer out of the box.
Input Sanitization Simulator
Type input, then compare how an unsanitized app vs a sanitized app would handle it.
Unsanitized (trusts raw input)
Sanitized (cleaned safely)
<, >, ', or ; — watch them get neutralized on the right. (Illustration only; nothing runs.)Unsafe Input Classifier
For each fictional input, decide whether it's safe or needs sanitizing. Instant feedback explains why.
Prompt: "AgriNova's ordering app passes search input straight into its database. Explain how input sanitization would protect the application."
Model answer: The app currently trusts raw user input, so crafted input could change how the app behaves (e.g., altering a database query). Input validation first checks the input is the expected type/format and rejects anything that isn't. Input sanitization then cleans or neutralizes dangerous characters so the input is treated as plain data, not as commands or code.
Why it mitigates risk: once input can no longer change the app's behavior, an entire class of application attacks is removed — this reduces the attack surface. Combined with secure-by-design review and secure defaults, the app is protected in layers.
Misconceptions That Cost AP Points
Recognize the wrong answer and you'll avoid writing it.
× "Secure by design and security by default are the same."
Secure by design = security built in while developing; security by default = the safest settings shipped on. Different stages, both needed.
AP trap: "built in from the start" vs "safe out of the box."
× "Validation and sanitization are interchangeable."
Validation accepts/rejects input by type/format; sanitization cleans dangerous characters. Strong apps do both.
AP trap: name the right one for the task.
× "Security can be added after launch."
Bolting on security later misses design-level flaws. Secure by design prevents weaknesses from the start.
AP trap: "we'll patch it later" is not secure by design.
× "Client-side checks alone are enough."
Attackers bypass the browser. Input must be validated/sanitized where the app actually trusts it (server side).
AP trap: front-end checks aren't the whole answer.
× "More features make an app safer."
Every feature is more code and more input — a bigger attack surface. Minimize to what's needed.
AP trap: "feature-rich" isn't "secure."
× "Secure defaults don't matter if users can change them."
Most users keep defaults. Shipping safe defaults protects the majority who never touch settings.
AP trap: defaults shape real-world safety.
Protection Reference + Practice Tools
A quick-reference table plus two hands-on tools: a hardening decision board and a secure launch review panel.
| Practice | Type | How it reduces attack surface |
|---|---|---|
| Threat modeling in planning | Secure by design | Prevents design-level weaknesses. |
| Ship with debug off / least privilege | Security by default | Users are safe without extra steps. |
| Validate input type/format | Input validation | Rejects malformed/unexpected input. |
| Sanitize dangerous characters | Input sanitization | Stops input from changing app behavior. |
| Disable unused features | Secure by design | Fewer entry points to attack. |
App Hardening Decision Board
Click a practice, then click the category it belongs to: Secure by Design, Security by Default, or Input Handling.
Secure by Design
Security by Default
Input Handling
Secure Launch Review Panel
For each launch item, mark PASS or FIX. Then run the review — the app can only "launch" when every item is correctly resolved.
Mini AP Quiz + Takeaways
Five quick AP-style questions with instant feedback, then your snapshot for review.
Mini AP-Style Quiz
Choose the best answer. Explanations appear instantly; your score totals at the end.
- 1Secure by design means security is built into the app from the very start of development.
- 2Security by default means the app ships with its safest settings already enabled.
- 3Input validation accepts/rejects input by type; input sanitization cleans dangerous characters.
- 4Sanitizing input stops it from changing the app's behavior — removing a whole class of attacks.
- 5Together these practices reduce the application's attack surface — the AP Mitigate Risk goal.
To explain how sanitization protects an app, say it neutralizes dangerous input so it's treated as plain data and can't change the app's behavior — which reduces the attack surface. Pair it with secure-by-design and secure defaults.
Practice — attempt these now.
AP-style assessments aligned to this lesson. Time them.