5.5 - Protecting Applications
Secure by Design
Secure by design means building security into every phase of development from the start, rather than bolting it on right before shipping. The traditional, insecure approach designs for functionality first, builds and tests features, and only adds security features near the very end, meaning fundamental design flaws often remain baked in. The secure by design approach instead treats security as a core requirement from day one: threat modeling happens during design, secure coding practices run throughout development, security testing happens continuously rather than just at the end, and a security review happens before release.
Secure by design is an initiative, pushed in the US by CISA (the Cybersecurity and Infrastructure Security Agency) since 2023, that encourages companies to include security in all phases of product development, starting with design. The big idea is that security becomes a design principle, not just a technical feature.
Three core principles drive this:
Ownership of customer security outcomes means companies take responsibility for their products' security rather than pushing that burden onto customers. For example, instead of shipping an IoT camera with a default password like "admin" and just telling customers in a manual to change it (something the vast majority never actually do, leading to things like massive botnets), a secure-by-design approach forces a unique password to be set during initial setup before the device will even function, putting the security burden on the manufacturer rather than the customer.
Radical transparency and accountability means openly and quickly sharing security information rather than treating it as something to hide, since secrecy doesn't actually make anyone more secure. This means promptly publishing security advisories, disclosing vulnerabilities once patches are available, sharing real details about what happened during an incident and how it was fixed, and maintaining an open vulnerability disclosure process. A company that quietly patches a vulnerability and hopes nobody notices leaves unpatched customers still exposed and unaware, whereas one that publishes a clear advisory with what's vulnerable, how to patch it, and any workarounds lets customers actually protect themselves and lets the broader industry learn from the incident.
Organizational structure for security means real leadership commitment and structural support, not just leaving it to a technical team to handle informally. This looks like having a C-level security executive, dedicated security budget and resources, security metrics built into performance reviews, mandatory security training, and embedding security directly into the development process (sometimes called DevSecOps) with review gates, threat modeling requirements, regular audits, and bug bounty programs. A company that shifts from treating security as an afterthought handled "when possible" to having a CISO reporting directly to the CEO, security embedded in every product team, clear remediation timelines, and dedicated development time for security work can see dramatic reductions in vulnerabilities and much faster incident response.
Secure by Default
Secure by default is one part of secure by design: secure by design covers how a product is planned and built, and secure by default covers the settings it ships with.
Secure by default means security features are already turned on right out of the box, without requiring the user to configure anything themselves. A secure-by-default router, for instance, forces creation of a unique password instead of shipping with a default one, has its firewall already enabled, has remote management already disabled, uses strong encryption like WPA3 automatically, and has automatic updates turned on from the start. An insecure-by-default router does the opposite: ships with a known default password, disables the firewall "for easier setup," leaves remote management on for convenience, and uses weak or no encryption, requiring the user to manually fix every one of these settings themselves, something most people never actually do.
The same principle applies to software, like a web server that's secure by default enabling HTTPS automatically, requiring a strong minimum TLS version, disabling weak ciphers, turning off directory listing, and suppressing overly detailed error messages, versus an insecure-by-default setup running plain HTTP, accepting outdated and insecure protocol versions, allowing weak ciphers, and exposing verbose error messages that leak system details. This matters enormously because the overwhelming majority of users never change default settings, most people don't have security expertise, ease of use tends to get prioritized over security in practice, and many organizations deploy products as-is without ever hardening them, meaning that whatever a product ships as, secure or not, is generally what stays deployed in the real world.
Input Sanitization
Applications rely on certain control characters to interpret input, things like a single quote to delimit a SQL string, a semicolon to end a SQL statement, angle brackets for HTML tags, slashes for file paths, double dashes to start a SQL comment, or percent signs as SQL wildcards. The vulnerability shows up when user-supplied input contains these characters and manages to break out of its intended context, letting an attacker manipulate the underlying logic.
Here's what "encasing" input looks like. Say a login page builds its database query by dropping the username between single quotes:
Template: SELECT * FROM users WHERE username = '[username]'; Input: maria Query: SELECT * FROM users WHERE username = 'maria';
The quotes mark where the user's input starts and stops, and the semicolon marks where the statement ends. That's why the single quote, the double quote (which encases input the same way in many languages), and the semicolon are the main control characters to watch. If the input contains one of them, the program can no longer tell where the data stops and the commands begin, which is exactly the opening an injection attack needs.
Input sanitization means checking that input matches what's actually expected and doesn't contain anything dangerous, generally through either sanitization (stripping or escaping dangerous characters) or validation with outright rejection (requiring input to match an expected pattern and refusing anything that doesn't).
Preventing SQL injection: unsanitized code that builds a query by directly concatenating raw username and password input lets an attacker submit something like a username ending in a quote followed by SQL comment characters, closing the string early and commenting out the rest of the query, including the password check, letting them log in as any user without ever knowing the real password. Sanitizing that input by stripping out dangerous characters like quotes, semicolons, and comment markers closes this hole. The best practice though is parameterized queries, where user input gets passed to the database separately from the query structure itself, so it's always treated strictly as data and never as executable SQL code, making injection essentially impossible regardless of what characters someone submits.
Preventing XSS: unsanitized code that drops raw user input like a posted comment directly into an HTML page lets an attacker submit something like a script tag that executes in every visitor's browser. The fix is output encoding, converting characters like angle brackets and quotes into their safe HTML entity equivalents (like
< becoming <), which means the browser displays the submitted text as plain text rather than executing it as code. An alternative or complementary approach is straightforwardly rejecting any input that contains HTML tags at all.Preventing directory traversal: unsanitized code that builds a file path directly from user input lets an attacker submit something like a string full of "../" sequences to climb out of the intended directory and reach sensitive system files like a password file. Sanitizing by stripping out those traversal sequences helps, but a stronger approach is validating against a whitelist of explicitly allowed filenames, or better still, using a secure path-joining approach that explicitly verifies the resulting resolved path stays within the intended base directory before ever opening the file.
A layered, defense-in-depth approach to input handling generally checks length first (rejecting excessively long input outright), then validates type and format against an expected pattern (like requiring a username to be alphanumeric within a certain length range, or an email to match a proper email format), then checks explicitly for dangerous characters and rejects input containing them, and finally applies appropriate encoding or escaping if the input's ultimately going to be displayed back to users. Running every piece of user input through layers like this before it's ever used keeps a single missed edge case from becoming a full vulnerability.
Summary
Secure by design rests on three pillars: companies owning their customers' security outcomes rather than offloading that responsibility, being radically transparent about vulnerabilities and incidents rather than hiding them, and building real organizational structure and leadership commitment around security rather than treating it as an afterthought. Secure by default means security is already switched on the moment something's deployed, since most users and organizations never go back and change default settings themselves. And input sanitization, whether through stripping dangerous characters, validating against strict patterns, using parameterized queries, or encoding output, is what actually stops SQL injection, XSS, and directory traversal attacks from succeeding. The underlying principle tying all of this together: treat every piece of user input as potentially malicious until it's been properly validated and sanitized, and build systems that default to safety rather than relying on someone remembering to turn security on later.