5.5: Protecting Applications

Essential Questions

• How does building security into the design phase prevent vulnerabilities that are expensive to fix later?
• What does it mean for software to be "secure by default," and why shouldn't users have to configure security settings?
• How do control characters in user input become attack vectors for SQL injection and XSS attacks?
• What is input sanitization, and how does it distinguish between legitimate data and malicious code?
• Why is taking ownership of customer security outcomes a fundamental responsibility for software companies?

Overview

Picture a house being built where the architect decides to add locks, alarms, and security cameras only after the walls are complete, the roof is on, and the family has moved in. The result would be awkward retrofits, incomplete coverage, and security measures that conflict with the home's basic structure. Unfortunately, this approach mirrors how many software applications are developed: security is treated as an add-on feature rather than a fundamental design principle.

This reactive approach creates applications riddled with vulnerabilities that are expensive to fix and difficult to secure comprehensively. Users find themselves struggling with complex security configurations, choosing between usability and safety, and falling victim to attacks that could have been prevented during the design phase. The cost—measured in data breaches, privacy violations, and lost trust—affects not just individual users but entire industries and economies.

The solution lies in two interconnected principles that are transforming how secure applications are built. Secure by design means integrating security considerations into every phase of software development, from initial concept through deployment and maintenance. Security by default means that applications should be secure to use immediately, without requiring users to understand or configure complex security settings. Together, these principles, combined with robust input sanitization techniques, create applications that resist attacks and protect users automatically.

The Application Security Principles of Secure by Design and Security by Default (5.5.A)

Secure by design represents a fundamental shift in how organizations approach application security. Instead of treating security as a feature to be added later, secure by design makes security a core design principle that influences every decision throughout the software development lifecycle. This approach recognizes that security vulnerabilities introduced during design and development are exponentially more expensive to fix after deployment than they are to prevent during the initial development process.

The secure by design initiative encompasses three foundational principles that guide how organizations should approach security. First, companies must take ownership of customer security outcomes. This means accepting responsibility for protecting users' data, privacy, and digital safety rather than shifting that burden to customers through complex configuration requirements or disclaimers. When a software vulnerability leads to a data breach, the company that created the vulnerable software bears responsibility for the customer harm, not just the immediate attacker who exploited the vulnerability.

Second, organizations must embrace radical transparency and accountability. This principle requires companies to communicate quickly and clearly about security issues, vulnerabilities, and incidents. Rather than minimizing problems or delaying disclosure, secure by design organizations proactively share security-related information that helps users and the broader security community respond effectively. This transparency extends to sharing threat intelligence, vulnerability information, and security best practices that can improve security for everyone.

Third, companies must build organizational structure and leadership to implement secure by design effectively. This isn't just about having a security team; it requires security-focused leadership that prioritizes customer security outcomes over short-term conveniences or cost savings. Security considerations must be integrated into business strategy, product development processes, and performance metrics. Organizations need leaders who understand that security isn't just a technical challenge but a fundamental business responsibility.

Within the secure by design framework, security by default represents the practical implementation of these principles in actual products. Security by default means that when users first encounter your application, the most secure configuration options are already enabled. Users shouldn't need to research security settings, understand complex trade-offs, or modify default configurations to achieve basic protection. The application should be secure to use immediately, out of the box.

Consider the difference between two approaches to password requirements. A traditional application might allow users to create weak passwords and then blame users when their accounts are compromised. A security by default application would enforce strong password requirements automatically, provide guidance for creating strong passwords, and offer built-in password management features. Users don't need to become password security experts; the application handles that complexity transparently.

This principle extends beyond individual security settings to encompass the entire user experience. Default privacy settings should protect user information rather than expose it. Default communication settings should use encryption rather than transmitting data in clear text. Default access controls should follow the principle of least privilege rather than granting broad permissions. The goal is to ensure that users who never modify any settings still receive strong security protection.

The implementation of security by default requires organizations to understand their users' security needs and threat models. A banking application faces different threats than a social media platform, and their default security postures should reflect those differences. However, both applications share the responsibility to protect users without requiring those users to become security experts.

Security by default also addresses the reality that most users don't modify default settings. Research consistently shows that the vast majority of users accept whatever configuration they encounter when first using an application. If the default configuration is insecure, most users will remain vulnerable. If the default configuration provides strong security, most users will be protected automatically.

The business benefits of secure by design and security by default extend beyond risk reduction. Organizations that implement these principles build customer trust, reduce support costs related to security incidents, and often discover that secure defaults actually improve user experience by eliminating complex security decisions. Users can focus on accomplishing their goals rather than managing security configurations.

How User Input Sanitization Protects Applications (5.5.B)

User input represents one of the most significant attack surfaces in modern applications. Every field where users can type text, upload files, or submit data creates a potential entry point for attackers who understand how applications process that input. The fundamental vulnerability arises from the way applications use control characters—special symbols like single quotes, double quotes, and semicolons—to structure and process the data users provide.

When applications receive user input, they typically embed that input within larger commands or queries. For example, when you search for products on an e-commerce site, the application might construct a database query that looks like this: SELECT * FROM products WHERE name CONTAINS 'user_input_here'. The single quotes around the user input are control characters that tell the database where the search term begins and ends. This structure works perfectly when users enter normal search terms like "laptop" or "coffee mug."

The problem emerges when users (or attackers) enter input that contains these same control characters. If an attacker enters laptop' OR 1=1 -- as their search term, the resulting query becomes SELECT * FROM products WHERE name CONTAINS 'laptop' OR 1=1 --'. The attacker's input has broken out of the intended search parameter and injected additional SQL code. The OR 1=1 condition will always be true, causing the query to return all products in the database, and the -- symbols comment out the remaining part of the query. This is a SQL injection attack.

Similar vulnerabilities exist wherever applications process user input. Cross-site scripting (XSS) attacks exploit the way web applications handle user input that contains HTML or JavaScript code. Directory traversal attacks manipulate file path inputs to access files outside the intended directory. Buffer overflow attacks send more data than the application expects to receive, potentially overwriting memory and executing malicious code.

User input sanitization provides the defense against these attacks by implementing verification functions that examine input before the application processes it. These functions can take two approaches: they can sanitize the input by removing or escaping potentially malicious characters, or they can reject the input entirely and force the user to provide different data. Both approaches aim to ensure that user input cannot break out of its intended context and manipulate the application's behavior.

Effective sanitization requires understanding the specific context where the input will be used. Input destined for a database query needs different sanitization than input that will be displayed on a web page or used to construct a file path. The sanitization process must account for all the control characters and special sequences that could be dangerous in that specific context.

For SQL injection prevention, sanitization typically involves escaping quote characters or using parameterized queries that separate the user input from the query structure. Instead of directly inserting user input into SQL strings, parameterized queries send the query structure and the user data separately to the database. The database engine handles the input safely, preventing it from being interpreted as SQL code.

XSS prevention focuses on HTML and JavaScript control characters. User input that will be displayed on web pages must have HTML tags either removed entirely or converted to safe display formats. For example, the <script> tag that could execute malicious JavaScript gets converted to <script> which displays as literal text rather than executing as code.

Directory traversal prevention examines file path inputs for sequences like ../ that could allow attackers to navigate to parent directories and access files outside the intended scope. Sanitization might remove these sequences entirely or validate that the final path remains within allowable directories.

Buffer overflow prevention involves checking the length of input data before processing it. If input exceeds the expected size limits, the application should reject it rather than attempting to process data that could overflow memory buffers.

The key insight is that sanitization must happen at the application boundary—before user input enters the core application logic. Once malicious input has been processed by vulnerable code, the damage is already done. Effective sanitization acts as a filter that ensures only safe, properly formatted data reaches the application's processing logic.

Modern application frameworks often provide built-in sanitization functions that handle common attack vectors automatically. However, developers must understand what protection these functions provide and ensure they're applied consistently throughout the application. Custom input processing code requires careful attention to sanitization requirements.

The layered security principle applies to input sanitization as well. Rather than relying on a single sanitization technique, robust applications use multiple complementary approaches: input validation at the user interface, sanitization at the application boundary, parameterized queries at the database layer, and output encoding when displaying data to users.

Input sanitization also requires ongoing attention as applications evolve. New input fields, modified processing logic, and updated frameworks can introduce new vulnerabilities or bypass existing protections. Regular security testing should include attempts to inject malicious input and verify that sanitization functions continue to work effectively.

The business impact of effective input sanitization extends beyond preventing attacks. Applications that properly handle malicious input provide more stable user experiences, suffer fewer crashes and unexpected behaviors, and demonstrate professionalism that builds customer confidence. The investment in robust input sanitization pays dividends in reduced security incidents, better application reliability, and stronger customer trust.

Real-World Impact

Consider the 2017 Equifax breach, where attackers exploited an unpatched vulnerability in a web application framework. The vulnerability allowed attackers to inject commands through user input that wasn't properly validated. This single input handling flaw led to the exposure of personal information for 147 million people. Proper input sanitization, combined with timely security updates, could have prevented this massive breach. The incident illustrates how input handling vulnerabilities can have far-reaching consequences that extend well beyond the immediate application.

Further Reading & Resources

• OWASP Secure Coding Practices
• CISA Secure by Design Initiative
• OWASP Input Validation Cheat Sheet
• SANS Secure Application Development
• Microsoft Security Development Lifecycle

References

• CISA Secure by Design Principles
• OWASP Secure Coding Practices Quick Reference Guide
• OWASP Input Validation Cheat Sheet Series