Application Security and Secure Software Development

Introduction

Application security is the discipline of protecting software, its data, users, and supporting infrastructure from unauthorized access, misuse, disruption, and modification. Because modern organizations deliver business services through web, mobile, cloud, and application programming interfaces (APIs), application weaknesses can become direct business risks. A vulnerable application may expose personal information, permit financial fraud, disrupt operations, or provide an attacker with a pathway into internal systems.

Secure software development treats security as a lifecycle responsibility rather than a final inspection activity. It combines threat modeling, secure design, secure coding, security testing, operational monitoring, and supply-chain governance. The objective is not to claim that software is perfectly secure; such a claim is unrealistic. The objective is to reduce the likelihood and impact of exploitation through informed design and continuous improvement.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain application security principles and the secure software development lifecycle.
2. Recognize common web and software vulnerabilities, including the OWASP Top 10 categories.
3. Construct a basic threat model using assets, actors, trust boundaries, and abuse cases.
4. Apply secure coding and defensive design practices.
5. Distinguish static, dynamic, dependency, interactive, and manual security testing.
6. Explain how DevSecOps integrates security into continuous delivery.
7. Evaluate software supply-chain risks and suitable governance controls.
8. Analyze an application-security incident and recommend proportionate controls.

1. Foundations of Application Security

Three traditional security objectives are confidentiality, integrity, and availability (the CIA triad). Confidentiality prevents unauthorized disclosure; integrity protects information and software from unauthorized alteration; availability ensures that authorized users can obtain services when needed. Application security also depends on authenticity, accountability, privacy, and resilience.

A useful security principle is least privilege: each user, process, service, and component receives only the permissions required for its legitimate task. Other important principles include secure defaults, complete mediation, separation of duties, defense in depth, fail-safe behavior, and minimizing attack surface.

Security controls may be preventive, detective, or corrective. Input validation and access control are preventive controls. Logging and alerting are detective controls. Credential rotation, patching, and incident recovery are corrective controls. Effective systems use several layers because any individual control can fail.

Important terminology

An asset is something valuable, such as customer data, credentials, source code, or service availability. A threat is a potential cause of harm. A vulnerability is a weakness that can be exploited. An exploit is a method or code that takes advantage of a vulnerability. Risk combines the likelihood of an adverse event with its potential impact. An attack surface is the collection of interfaces through which a system can be attacked, including endpoints, APIs, administrative functions, dependencies, and exposed infrastructure.

Authentication establishes who or what a subject is. Authorization determines what that subject may do. These functions must not be confused: a successfully authenticated user is not automatically authorized to access every record or operation.

2. The Secure Software Development Lifecycle

A secure software development lifecycle (SSDLC) embeds security activities in all development phases:

Security requirements should be testable. “The system must be secure” is not a useful requirement. “A user may access records only when an authorization policy permits access to that record” can be implemented and tested.

The cost of correcting a defect generally increases when it is discovered later, because later changes affect more code, documentation, testing, and deployed systems. This is an engineering observation rather than a universal numerical law. Early analysis is valuable, but it does not eliminate the need for operational monitoring and incident response.

3. Threat Modeling

Threat modeling is a structured method for anticipating how a system could be misused. A practical process is:

1. Define scope, business purpose, and security objectives.
2. Identify assets and stakeholders.
3. Draw the major components, data flows, and trust boundaries.
4. Identify threats and abuse cases.
5. Estimate likelihood and impact.
6. Select mitigations and assign owners.
7. Validate the model when the system changes.

A data-flow diagram should show clients, services, databases, external providers, protocols, and boundaries where trust or privilege changes. Threats can be organized using STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. STRIDE is a prompting framework, not a complete risk calculation.

For a simple qualitative risk assessment, a team may classify likelihood and impact as low, medium, or high. A numerical score can be used only if the organization defines consistent scales and decision thresholds. A score is not an objective measurement of truth; it supports prioritization.

Threat modeling should include misuse by legitimate users, compromised accounts, malicious insiders, vulnerable dependencies, cloud misconfiguration, and failures in external services. Privacy threats—such as excessive collection, secondary use, and re-identification—should be considered alongside technical threats.

4. Common Web and Software Vulnerabilities

The OWASP Top 10 is an awareness document for major web application risk categories. The 2021 edition lists the following categories:

Injection

Injection occurs when data is interpreted as instructions. SQL injection is a common example: if an application constructs a query by concatenating user input, an attacker may alter the query’s meaning. Parameterized queries separate code from data. Input validation remains useful, but it is not a substitute for safe interpreter APIs. The same principle applies to operating-system commands, template engines, LDAP, and other interpreters.

Output encoding must match context. HTML encoding, JavaScript encoding, URL encoding, and SQL parameterization solve different problems. A general “sanitize everything” function is unsafe because the correct transformation depends on where data is placed.

Broken access control

Authorization must be enforced on the server for every sensitive operation and object. Client-side controls such as hidden buttons improve usability but do not provide security. Developers should test horizontal privilege escalation (one user accessing another user’s objects) and vertical escalation (a normal user invoking administrative functions).

Authentication and session weaknesses

Passwords should be handled using a modern, slow, salted password-hashing scheme rather than reversible encryption or plaintext storage. Authentication systems should support appropriate multi-factor authentication, protect recovery workflows, limit abusive attempts without creating easy denial-of-service, and invalidate sessions after high-risk events. Session identifiers must be unpredictable, protected in transit, and handled with suitable cookie attributes such as Secure and HttpOnly where applicable.

Cryptographic failures

Encryption is effective only when algorithms, modes, keys, certificates, storage, rotation, and endpoint verification are managed correctly. Sensitive data should not be collected or retained without a justified purpose. Transport encryption protects data in transit but does not automatically protect compromised endpoints or improperly authorized users.

Misconfiguration and information exposure

Production systems should not expose debugging interfaces, default credentials, internal stack traces, unnecessary ports, or administrative endpoints. Error messages should help legitimate operators without revealing secrets or implementation details to attackers. Configuration should be versioned, reviewed, automatically tested, and separated from source-code secrets.

Insecure deserialization and software integrity

Deserializing attacker-controlled objects can trigger unexpected behavior, including code execution. Safer approaches include simple data formats, strict schemas, type restrictions, and integrity validation. Build systems must also protect source repositories, package managers, build runners, release artifacts, and deployment credentials.

5. Secure Coding and Defensive Design

Secure coding begins with explicit assumptions. Developers should define accepted input, expected types, maximum lengths, encoding, error behavior, and authorization rules. Input validation should be allowlist-based where feasible and should occur at a trust boundary. Validation is not a complete defense against injection; the relevant interpreter API must still be used safely.

Sensitive values should not appear in source code, logs, URLs, crash reports, or test data. Secrets belong in an approved secrets-management system, with access controls, auditing, rotation, and emergency revocation. Logging should record security-relevant events—such as authentication failures, permission changes, and administrative actions—without recording passwords, access tokens, or unnecessary personal data.

Race conditions occur when security decisions and actions are separated in time. For example, checking that a file is safe and then opening a different file identified by a changeable path can produce a time-of-check/time-of-use flaw. Atomic operations, safe handles, and controlled resource ownership reduce this risk.

Secure APIs should use explicit authorization, consistent error handling, bounded resource use, timeouts, replay protection where necessary, and strict schema validation. Rate limits and quotas protect both availability and financial resources. Security controls should be centralized where consistency matters, but business-specific authorization decisions must still be evaluated in the correct context.

6. Security Testing and Assurance

No single testing method finds every defect.

• Static application security testing (SAST): analyzes source or compiled code without executing it. It is useful early but may produce false positives and miss runtime configuration problems.
• Dynamic application security testing (DAST): interacts with a running application. It can discover observable behavior but may not reach hidden code paths.
• Software composition analysis (SCA): inventories open-source and third-party components, license information, and known vulnerabilities.
• Interactive application security testing (IAST): combines runtime observation with instrumentation and can provide code-level context.
• Fuzz testing: supplies large quantities of malformed or unexpected input to identify crashes and incorrect handling.
• Manual review and penetration testing: examine business logic, architecture, authorization, and realistic attack paths that automated tools may miss.

Tests should be risk-based. A public payment API deserves deeper testing than an isolated internal display component, although internal systems are not automatically trusted. Findings should be triaged by exploitability, affected assets, exposure, compensating controls, and business impact. A vulnerability scanner’s severity rating is an input to judgment, not a complete risk decision.

Security regression tests convert fixed vulnerabilities into repeatable checks. Tests should run in development and continuous integration, while dynamic and manual assessments are scheduled according to risk and change. Test environments must protect real data and credentials.

7. DevSecOps

DevSecOps integrates security into development and operations through shared responsibility, automation, rapid feedback, and measurable risk management. A secure pipeline may include:

1. Pre-commit secret and policy checks.
2. Code review and SAST during continuous integration.
3. Dependency and license analysis.
4. Unit, integration, API, and security regression tests.
5. Container and infrastructure-as-code scanning.
6. Artifact signing, provenance generation, and controlled promotion.
7. DAST or targeted security tests in a staging environment.
8. Production monitoring, vulnerability management, and incident feedback.

“Shift left” is useful when it means finding defects earlier, but security must also “shift right” into runtime detection, response, and learning. Automated gates should be proportionate. Blocking every low-confidence warning encourages developers to bypass controls; allowing critical exploitable defects to ship creates unacceptable exposure.

Useful measures include remediation time by severity, percentage of critical components with known owners, test coverage for high-risk requirements, dependency age, secret-detection incidents, and recurrence of previously fixed defects. Metrics should improve decisions rather than reward teams for manipulating numbers.

8. Software Supply-Chain Security

Applications are assembled from internal code, open-source packages, commercial libraries, container images, build tools, cloud services, and deployment templates. A supply-chain attack may compromise a maintainer, package repository, build runner, update mechanism, or developer account.

Core controls include:

• Maintain a software bill of materials (SBOM) identifying components and versions.
• Pin or constrain dependency versions and verify trusted sources.
• Review transitive dependencies and remove unnecessary packages.
• Scan for vulnerabilities and monitor advisories.
• Use lockfiles and reproducible or repeatable builds where practical.
• Sign artifacts and verify signatures before deployment.
• Generate attestations describing how and where artifacts were built.
• Restrict CI/CD permissions and isolate build runners.
• Protect package-publishing credentials with MFA and short-lived access.
• Establish a process for emergency response to vulnerable dependencies.

An SBOM improves visibility but does not prove that a component is safe. A signed artifact proves that a particular key signed it; it does not prove that the signer’s process was uncompromised. Controls therefore need layered evidence and governance.

9. Governance, Ethics, and Regulation

Application security involves ethical obligations because software decisions affect people who may have no control over the design. Organizations should minimize personal-data collection, define retention periods, provide appropriate transparency, and restrict secondary use. Privacy and security controls should be considered during design rather than added after deployment.

Security testing must be authorized, scoped, and conducted without unnecessary disruption. Researchers need a responsible vulnerability-disclosure channel, clear rules of engagement, and prompt remediation procedures. Organizations may also have obligations under data-protection, breach-notification, financial, health, accessibility, or sector-specific regulations. Legal compliance is a baseline, not a guarantee of good security.

AI-assisted coding can improve productivity but introduces risks: insecure generated code, hallucinated libraries, copied vulnerable patterns, leakage of proprietary prompts or source code, and unclear authorship. AI output requires human review, testing, dependency verification, and compliance with organizational policy. An AI tool should not receive secrets or regulated data unless its handling has been approved.

10. Illustrative Case: An Online Retail API

Background

An online retailer launched an API for mobile shopping. Customers could view orders, cancel eligible orders, and request refunds. The system used a web gateway, an order service, a payment provider, and a relational database.

Problem

A security review found that the endpoint /orders/{id} returned an order whenever the requester was authenticated. The service checked authentication but did not verify that the order belonged to the requester or that the requester had an administrative role. In addition, a search function built database queries through string concatenation, and the deployment pipeline automatically installed the latest package versions without an inventory or approval process.

Analysis

The order defect was broken access control and created a horizontal privilege-escalation risk. The query construction created injection risk. Uncontrolled dependency updates created supply-chain and vulnerable-component risk. The design review also found that refund actions lacked a strong step-up check and that logs included excessive payment-related data.

Approach and solution

The retailer introduced centralized, server-side authorization policies that evaluated both subject and object ownership. It replaced query concatenation with parameterized database access and added negative authorization tests. Refunds required a re-authentication or additional verification step according to risk. The team deployed SAST, DAST, and SCA checks in the pipeline, created an SBOM, restricted build permissions, and required signed artifacts. Logs were redesigned to capture event identifiers and outcomes without storing sensitive payment data. A threat model was updated whenever API contracts or payment flows changed.

Outcome

Testing confirmed that customers could access only their own orders, administrative operations were separated, and malicious query input was treated as data. Dependency changes became visible and reviewable. The organization also improved detection of unusual refund activity through monitoring.

Learning points

The incident was not caused by one defective line alone. It resulted from confusing authentication with authorization, insufficient threat modeling of business actions, weak dependency governance, and incomplete testing. Effective application security combines design decisions, implementation controls, pipeline checks, and operational feedback.

Challenges and Limitations

Security controls create trade-offs. Strong authentication can increase friction; extensive logging can create privacy and storage risks; aggressive scanning can slow delivery; dependency updates can introduce compatibility defects; and strict network controls can obstruct legitimate integrations. Teams should document risk decisions, use compensating controls when necessary, and revisit assumptions as threats and systems change.

The OWASP Top 10 is educational and cannot replace a system-specific threat model. Automated tools are valuable but imperfect, and a clean scan does not demonstrate absence of vulnerabilities. Security is also affected by organizational incentives, staffing, procurement, legacy systems, and incident-response capability. Sustainable security therefore requires leadership support, skilled personnel, usable processes, and continuous learning.

Best-Practice Checklist

• Model threats before major design decisions and after significant changes.
• Enforce authorization on the server for every protected object and action.
• Use parameterized queries and context-appropriate output encoding.
• Protect secrets, keys, sessions, and personal data throughout their lifecycle.
• Keep dependencies inventoried, supported, reviewed, and rapidly patchable.
• Automate security checks while retaining expert manual assessment.
• Sign and verify build artifacts; restrict CI/CD identities and permissions.
• Monitor security events and test incident-response procedures.
• Convert important findings into regression tests.
• Treat security, privacy, and ethics as shared responsibilities.

Chapter Summary

Application security protects software, data, users, and services throughout the SSDLC. Core principles include least privilege, secure defaults, defense in depth, separation of duties, and fail-safe behavior. Threat modeling identifies assets, trust boundaries, abuse cases, and mitigations before implementation. The OWASP Top 10 provides a practical awareness framework covering access control, cryptographic failures, injection, insecure design, misconfiguration, vulnerable components, authentication failures, integrity failures, logging weaknesses, and SSRF. Secure coding requires safe interpreter APIs, explicit authorization, protected secrets, careful error handling, and bounded resource use. SAST, DAST, SCA, fuzzing, manual review, and penetration testing provide complementary assurance. DevSecOps integrates these activities into delivery pipelines and operations. Finally, SBOMs, signed artifacts, provenance, dependency governance, and protected build systems reduce supply-chain risk. No tool or framework guarantees security; effective practice is continuous, risk-based, ethical, and evidence driven.

Key Terms

Asset: Something valuable that requires protection.

Attack surface: The interfaces and components exposed to possible attack.

Authentication: Establishing the identity of a subject.

Authorization: Determining what an authenticated subject may do.

Confidentiality: Preventing unauthorized disclosure of information.

DevSecOps: Integrating security into development, delivery, and operations.

Exploit: A method that takes advantage of a vulnerability.

Injection: Causing untrusted data to be interpreted as instructions.

Integrity: Protection against unauthorized alteration.

Least privilege: Granting only the permissions necessary for a task.

OWASP Top 10: A widely used awareness list of major web application risk categories.

SAST: Static analysis of application code or compiled representations.

SBOM: A structured inventory of software components and versions.

SSDL/SSDLC: A development lifecycle that incorporates security activities.

SSRF: Server-Side Request Forgery, in which a server is induced to make unintended requests.

Threat model: A structured representation of assets, threats, trust boundaries, and mitigations.

Vulnerability: A weakness that may be exploited.

Vulnerability management: The process of identifying, prioritizing, correcting, and monitoring weaknesses.

Review Questions

Short Answer Questions

1. What is the difference between authentication and authorization?
2. Why are parameterized queries preferred to string concatenation?
3. Name four activities performed during threat modeling.
4. What information does an SBOM provide?
5. Why is a security scanner’s result not a complete risk decision?

Long Answer Questions

1. Explain how security can be integrated into each phase of the secure software development lifecycle.
2. Describe the major OWASP Top 10 categories and give an appropriate control for at least six of them.
3. Compare SAST, DAST, SCA, fuzz testing, and manual penetration testing, including the limitations of each.
4. Explain how DevSecOps and supply-chain security reinforce one another.
5. Discuss the ethical and privacy responsibilities involved in application security testing and logging.

Analytical / Application Questions

1. A banking API verifies that a customer is logged in but allows the customer to modify any account identified in a URL. Identify the vulnerability, explain the attack path, and propose layered controls.
2. A development team wants to block every automated security finding before deployment. Analyze the benefits and risks of this policy and recommend a proportionate alternative.
3. Design a basic threat model for a student-records application. Identify at least three assets, two trust boundaries, three threats, and suitable mitigations.

Multiple Choice Questions with Answers

Question 1

Which control most directly prevents SQL injection?

A. Parameterized queries

B. Hiding the database error page

C. Increasing session duration

D. Adding a client-side login button

Correct Answer: A. Parameterized queries

Question 2

A logged-in customer accesses another customer’s order by changing an order identifier. Which vulnerability is demonstrated?

A. Cross-site request forgery

B. Broken access control

C. Cryptographic failure

D. Denial of service

Correct Answer: B. Broken access control

Question 3

What is the primary purpose of threat modeling?

A. To replace all security testing

B. To identify threats and select mitigations during design

C. To compress application binaries

D. To measure network bandwidth

Correct Answer: B. To identify threats and select mitigations during design

Question 4

Which activity is characteristic of software composition analysis?

A. Inventorying dependencies and checking known vulnerabilities

B. Testing only the visual design of a user interface

C. Replacing authorization with encryption

D. Deleting unused production logs

Correct Answer: A. Inventorying dependencies and checking known vulnerabilities

Question 5

Which statement about client-side authorization controls is correct?

A. They are sufficient because users cannot see server code

B. They improve usability but must be enforced on the server

C. They eliminate the need for authentication

D. They protect against all injection attacks

Correct Answer: B. They improve usability but must be enforced on the server

Question 6

What does an SBOM primarily provide?

A. A list of software components and their versions

B. A guarantee that all software is vulnerability-free

C. A replacement for incident response

D. A password database

Correct Answer: A. A list of software components and their versions

Question 7

Which OWASP category includes unsafe default settings and exposed debugging interfaces?

A. Security misconfiguration

B. Identification and authentication failures

C. Server-side request forgery

D. Insecure design

Correct Answer: A. Security misconfiguration

Question 8

Which practice best protects build integrity in a CI/CD pipeline?

A. Allowing all developers to publish releases

B. Signing artifacts and verifying provenance before deployment

C. Installing unreviewed packages automatically

D. Disabling audit logs to improve speed

Correct Answer: B. Signing artifacts and verifying provenance before deployment

Question 9

What is a limitation of DAST?

A. It cannot interact with a running application

B. It may fail to reach hidden code paths or unexposed functionality

C. It only detects dependency license problems

D. It always produces zero false positives

Correct Answer: B. It may fail to reach hidden code paths or unexposed functionality

Question 10

Which principle grants a service only the permissions it needs to perform its function?

A. Complete mediation

B. Least privilege

C. Open design

D. Fail-open behavior

Correct Answer: B. Least privilege