Skip to main content

Unit 5 · Topic 5.5

5.5 Protecting Applications

The cheapest security is the kind built in from the start. This topic covers secure by design and secure by default, the principles that make companies responsible for their products' security, and input sanitization, the coding habit that blocks many SQL injection, XSS and directory traversal attacks.

Key terms

  • secure by design
  • secure by default
  • input sanitization
  • control characters
  • data validation

Secure by design

Secure by design is an approach, promoted by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) since 2023, that asks companies to include security in every phase of building a product, starting with its design. Security becomes a design principle, not a feature added at the end. It rests on three principles:

  • Take ownership of customer security outcomes. Build products that meet customers' real security needs, rather than leaving customers to fix weaknesses themselves.
  • Embrace radical transparency and accountability. Share security news and updates about products quickly, because openness makes everyone safer.
  • Lead from the top. Build an organization and leadership team that puts security first.

Secure by default

Secure by default is part of secure by design. It means a product's security features are turned on out of the box. A customer who never touches the settings should still be safe.

Compare two home routers. One ships with the login admin/admin for every unit and remote management turned on; the owner must find and change both. The other ships with a unique random password printed on each unit, forces a password change at first login, turns on automatic updates and keeps remote management off until the owner enables it. The second router is secure by default.

Sanitizing user input

When an application processes your input, it usually wraps it in special characters so the program knows where the input starts and ends. These are control characters, and they include the single quote, the double quote and the semicolon. If an adversary types control characters into a field, they can end the input early and make the rest be treated as instructions. That's the core of SQL injection.

Programmers defend against this with a verification function that checks every input against what's expected and looks for control characters that could manipulate the system. When it finds a problem, it can either sanitize the input (remove the dangerous characters) or reject it with an error and ask for different input. Done consistently, this blocks many SQL injection, XSS and directory traversal attacks.

The strongest checks describe what's allowed, not just what's banned. A five-digit ZIP code field should accept exactly five digits. A quantity field should accept only a whole number in a sensible range. Anything else gets rejected. (Professional developers also use parameterized queries, which keep user input separate from database commands entirely. The course focuses on validation and sanitization.)

Worked examples

Try each one yourself first, then open the solution.

  1. Example 1

    Designing input checks

    A school's lunch-ordering web app has three fields: student ID (always 6 digits), quantity (1 to 5) and a comment box. Describe a check for each field and the attack each check helps block.

    Show the solution
    1. Step 1: Student ID: accept exactly 6 digits and nothing else. Quotes, semicolons or SQL words are rejected, which blocks SQL injection through this field.
    2. Step 2: Quantity: accept only a whole number from 1 to 5. That blocks injected commands and absurdly large values.
    3. Step 3: Comment box: free text is needed, so sanitize it. Remove or encode control characters and HTML tags like script tags before storing or showing it. That blocks stored XSS and SQL injection, and a length limit guards against oversized input.
    4. Step 4: Check every field on the server, since an adversary can skip any checks that run only in the browser.

    Answer: ID: exactly 6 digits (blocks SQL injection). Quantity: whole number 1–5 (blocks injection and out-of-range values). Comments: strip or encode control characters and tags and limit length (blocks XSS and SQL injection). Validate on the server.

  2. Example 2

    Secure by design or by default?

    Classify each as an example of secure by default, radical transparency, or ownership of customer security outcomes: (a) a smart camera maker publishes a security notice the same day it learns of a flaw; (b) a video app ships with two-step login already turned on; (c) a software company fixes a whole class of bugs in its product instead of telling customers to buy a separate security add-on.

    Show the solution
    1. Step 1: (a) Sharing security news quickly and openly: radical transparency and accountability.
    2. Step 2: (b) A security feature enabled out of the box: secure by default.
    3. Step 3: (c) The company takes responsibility instead of shifting the burden to customers: ownership of customer security outcomes.

    Answer: (a) Radical transparency. (b) Secure by default. (c) Ownership of customer security outcomes.

Common mistakes

  • Treating secure by design and secure by default as unrelated. Secure by default is one part of secure by design.
  • Thinking sanitization only matters for SQL injection. The same checks help block XSS and directory traversal.
  • Checking input only in the browser. Adversaries can send requests directly to the server, so validation has to happen there too.

On the exam

  • Expect questions asking how sanitization protects an application. Name the control characters (quotes and semicolons), say the function removes them or rejects the input, and name the attacks it stops.
  • For secure by design, be ready to match an example to one of the three principles or to secure by default.

Connected topics

Videos

  • Application Security - CompTIA Security+ SY0-701 - 4.1

    Professor MesserWatch on YouTube (opens in a new tab)

  • 10 Principles for Secure by Design: Baking Security into Your Systems

    IBM TechnologyWatch on YouTube (opens in a new tab)

  • SQL Injection Prevention: Security Simplified

    Vickie Li DevWatch on YouTube (opens in a new tab)

  • How To Prevent The Most Common Cross Site Scripting Attack

    Web Dev SimplifiedWatch on YouTube (opens in a new tab)

  • Application Security 101 - What you need to know in 8 minutes

    SnykWatch on YouTube (opens in a new tab)

Check yourself: 5.5 Protecting Applications

4 questions on 5.5 Protecting Applications. Pick an answer to see if you got it, and why.

Question 1 of 4

Which product best shows the principle of secure by default?

A software company announces three commitments:

Commitment 1: "We will build our products to meet our customers' security needs, and we accept responsibility for how secure our customers end up being."

Commitment 2: "When we find a security problem in our products, we will tell customers quickly and share what we are doing about it."

Commitment 3: "Our leadership team will include an executive whose job is to make security a top priority in every product decision."

Invented company statement

Question 2 of 4

Which principle of secure by design does Commitment 2 reflect?

Question 3 of 4

What do the three commitments together show about secure by design?

Question 4 of 4

Which set lists control characters that applications commonly use to enclose user input?

0 of 4 answered