Application, API and DevSecOps Security

Introduction

Modern software is a primary target of cyberattack because applications process identities, money, business records, and personal information. A secure network cannot compensate for an application that trusts unvalidated input, exposes excessive data, or mishandles authorization. Application security therefore concerns the design, implementation, deployment, operation, and retirement of software systems.

This chapter examines security for web applications, mobile applications, and application programming interfaces (APIs). It connects secure coding and threat modeling with code review, security testing, the OWASP guidance, software supply-chain protection, and vulnerability remediation. It also explains DevSecOps: the integration of security activities into the software development life cycle (SDLC) and CI/CD rather than treating security as a final inspection.

Security is not a single tool. It is a risk-management discipline involving people, processes, architecture, code, infrastructure, and governance. Effective practice aims to reduce the likelihood and impact of compromise while preserving usability, performance, accessibility, and maintainability.

Learning Objectives

After studying this chapter, a student should be able to:

1. Explain the major security risks affecting web, mobile, and API systems.
2. Apply threat modeling to identify assets, trust boundaries, threats, and mitigations.
3. Use secure-coding principles for input handling, authentication, authorization, session management, cryptography, and error handling.
4. Distinguish static, dynamic, interactive, dependency, and manual security testing.
5. Explain the role of OWASP guidance in application-security practice.
6. Design security controls for CI/CD pipelines and software supply chains.
7. Prioritize and remediate vulnerabilities using evidence-based risk analysis.
8. Evaluate the ethical, legal, and governance responsibilities of application-security professionals.

1. Application Security as a Systems Discipline

Application security protects software and the information it handles against unauthorized disclosure, alteration, destruction, and misuse. The familiar confidentiality, integrity, and availability (CIA) objectives remain important, but modern applications also require:

• Authenticity: confidence that a user, service, or message is genuine.
• Accountability: the ability to associate actions with responsible identities and reliable audit records.
• Privacy: appropriate collection, use, retention, and disclosure of personal data.
• Resilience: the ability to continue or safely recover operations during failures and attacks.

A vulnerability is a weakness that can be exploited. A threat is a potential cause of harm, while an exploit is a technique or code that takes advantage of a vulnerability. Risk combines the possibility of an adverse event with its consequences. A simple qualitative model is:

Likelihood and impact may be rated qualitatively, such as low, medium, and high, or quantitatively when reliable data exists. The expression is a decision aid, not a universal physical law: organizations must define their rating scales and consider uncertainty, control effectiveness, and exposure.

A secure design uses defense in depth. For example, an online banking transfer may be protected by transport encryption, authenticated sessions, server-side authorization, transaction limits, anomaly detection, audit logging, and recovery procedures. Failure of one control should not automatically produce catastrophic compromise.

2. Web, Mobile, and API Attack Surfaces

Web applications

Web applications commonly include browsers, web servers, application services, databases, identity providers, file stores, and third-party services. Important attack surfaces include URL parameters, request bodies, cookies, headers, file uploads, administrative functions, and error responses.

Common classes of weakness include injection, broken access control, authentication failures, insecure design, security misconfiguration, vulnerable components, cryptographic failures, software and data integrity failures, logging deficiencies, and server-side request forgery. These categories correspond closely to themes in the OWASP Top 10, although the exact list and wording evolve.

Mobile applications

A mobile application should not be treated as a trusted container merely because it runs on a user’s device. Attackers can inspect binaries, modify runtime behavior, extract local data, observe network traffic on compromised devices, and automate requests directly against backend services. Consequently:

• sensitive authorization decisions belong on trusted servers;
• secrets should not be embedded in application binaries;
• local storage should use platform-provided protected mechanisms where appropriate;
• deep links and exported components require authorization checks;
• certificate validation and secure transport must be correctly implemented;
• mobile APIs must assume that requests can be forged outside the official app.

Obfuscation can increase the cost of reverse engineering, but it is not a substitute for server-side controls. Root or jailbreak detection may provide a signal, yet it can be bypassed and should not be the sole security boundary.

APIs

An API is a contract through which software components exchange data or invoke operations. API security must address both the transport and the business meaning of each request. Important risks include object-level authorization failures, excessive data exposure, unrestricted resource consumption, weak authentication, unsafe consumption of third-party APIs, and incorrect configuration.

An API gateway can enforce rate limits, authentication integration, schema validation, and observability, but it cannot replace authorization inside the service. Each service should verify that the authenticated principal is permitted to perform the requested action on the specified object and within the relevant business context.

3. Threat Modeling and Secure Design

Threat modeling is a structured method for identifying what can go wrong before or during implementation. It is most valuable when performed early, when architectural changes are less expensive.

A practical process is:

1. Define scope and objectives. Identify system boundaries, important use cases, assumptions, and security requirements.
2. Identify assets. Examples include credentials, payment records, health information, source code, signing keys, and service availability.
3. Draw data-flow diagrams. Show processes, data stores, external entities, data flows, and trust boundaries.
4. Enumerate threats. STRIDE is a useful model: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
5. Estimate risk. Consider exploitability, exposure, affected users, business impact, and existing controls.
6. Select mitigations. Prefer architectural prevention, then strong implementation controls, detection, and response.
7. Validate residual risk. Record accepted risks, owners, assumptions, and review dates.

A trust boundary is a point at which the level of trust changes, such as the boundary between a browser and server, a service and database, or an organization and a payment provider. Data crossing a boundary must be authenticated, authorized, validated, and protected according to its sensitivity.

Threat modeling should be iterative. A new payment provider, data field, mobile feature, or deployment platform can change the threat model. Threat models should therefore be linked to architecture decisions, security requirements, test cases, and change-management records.

Security requirements and abuse cases

Functional requirements state what a system should do; security requirements state the constraints under which it must do it. Examples include:

• A user may download an invoice only if the invoice belongs to that user’s authorized organization.
• Password-reset tokens must be single-use and expire after a defined period.
• Administrative actions must be logged with actor, target, time, outcome, and correlation identifier.
• A service must reject requests that exceed defined resource limits.

An abuse case describes how a malicious or unauthorized actor may misuse a feature. For a file-upload function, abuse cases include uploading executable content, exhausting storage, bypassing content checks, and obtaining another user’s file through predictable identifiers.

4. Secure Coding Principles

Input validation and output encoding

Validation should occur on the server, close to the point of use, and should apply allowlists where feasible. A validator should check type, syntax, length, range, encoding, and business constraints. Validation is not the same as sanitization; removing suspicious characters may change data unpredictably and does not reliably prevent all attacks.

Output encoding is context-specific. HTML, JavaScript, CSS, URL, SQL, and operating-system command contexts require different defenses. A value safe in an HTML text node may be unsafe in a JavaScript string or an HTML attribute. Framework auto-escaping should be enabled, and raw-output features should be narrowly controlled.

Injection prevention

Injection occurs when untrusted data is interpreted as commands or code. Parameterized queries separate SQL instructions from values. Safe APIs should be used for operating-system processes, directory access, template rendering, and directory services. If dynamic identifiers such as column names are unavoidable, they should be selected from a fixed server-side allowlist rather than inserted directly from user input.

Authentication and password security

Authentication establishes identity; authorization determines permitted actions. Passwords should be stored using a slow, adaptive, salted password-hashing function such as Argon2id, bcrypt, or scrypt, configured according to current organizational guidance. Passwords must not be stored as plaintext or with fast general-purpose hashes alone.

Multifactor authentication reduces the consequences of password compromise. Recovery flows require the same care as login: reset tokens should be unpredictable, short-lived, single-use, bound to the intended account, and protected against account enumeration.

Authorization

Authorization should be explicit, centralized where practical, and enforced on every sensitive operation. The server must not trust hidden form fields, client-side role indicators, object identifiers, or mobile-app behavior. Least privilege means granting only the permissions needed for a task and limiting service accounts, database users, and deployment identities accordingly.

A useful review question is: “Can a user change the identifier in this request and access another user’s object?” This tests for broken object-level authorization, one of the most significant API risks.

Session management

Session identifiers should be unpredictable, transmitted only over protected channels, and protected with appropriate cookie attributes such as Secure, HttpOnly, and an intentional SameSite policy. Sessions should expire according to risk, be invalidated after logout or reauthentication where appropriate, and be rotated after privilege changes. Applications must defend against cross-site request forgery for browser-based state-changing requests, using suitable tokens, same-site controls, origin checks, or a combination.

Cryptography and secrets

Use established, reviewed cryptographic libraries and protocols. Do not invent encryption algorithms or reuse keys for unrelated purposes. Protect keys through a secrets-management or key-management system, define rotation and revocation procedures, and restrict access. Encryption in transit does not protect data after an authorized service has decrypted it; authorization, logging, and data minimization remain necessary.

Errors, logging, and privacy

Errors shown to users should be useful without disclosing stack traces, queries, tokens, or internal topology. Detailed diagnostic information belongs in protected logs. Logs should support investigation but must not record passwords, session tokens, or unnecessary sensitive personal data. Access to logs requires authorization, and retention should reflect legal, operational, and privacy requirements.

5. Code Review and Security Testing

Security review combines human reasoning with automated tools. No tool detects every design flaw, and a clean scan does not prove that a system is secure.

A secure code review should examine authentication, authorization, input and output handling, cryptographic use, error paths, concurrency, file operations, dependency calls, logging, and tests. Reviewers should inspect negative cases, not only the successful business workflow.

Security tests should be traceable to requirements and threats. For example, a requirement that users may view only their organization’s invoices should produce tests for same-user access, cross-user access, cross-organization access, altered identifiers, missing authentication, and race or caching conditions.

Testing environments must be controlled. Dynamic testing against production without explicit authorization can disrupt services or expose personal data. Test data should be synthetic or minimized, and security findings should be protected as sensitive information.

6. DevSecOps and the Secure SDLC

DevSecOps integrates security into development and operations while preserving rapid, automated delivery. It does not mean adding a security scanner to a pipeline and calling the problem solved. It requires shared ownership, automated feedback, risk-based gates, secure defaults, and measurable improvement.

Figure: Security activities are integrated across the software development life cycle, with operational feedback informing subsequent planning.

A mature pipeline commonly performs formatting and unit tests, secret scanning, software composition analysis, static analysis, infrastructure-as-code checks, container-image scanning, integration tests, dynamic testing, and deployment-policy checks. Controls should be staged according to speed and cost. A leaked credential should block a build immediately; a low-confidence informational finding may create a tracked issue instead of stopping every deployment.

Pipeline security itself is critical. Protect build agents, restrict credentials, separate environments, require review for workflow changes, pin or verify action versions, record provenance, and prevent untrusted pull requests from accessing production secrets. Deployment identities should be short-lived and scoped to the minimum permissions.

7. Software Supply-Chain Security

Applications depend on libraries, operating-system packages, container images, build tools, plugins, and external services. Supply-chain attacks may involve malicious packages, compromised maintainers, dependency confusion, typosquatting, tampered artifacts, or stolen signing credentials.

Organizations should maintain an accurate software bill of materials (SBOM), use trusted registries, verify package integrity, pin versions where appropriate, review transitive dependencies, and monitor vulnerability advisories. Reproducible or attestable builds improve confidence that released artifacts correspond to reviewed source. Digital signatures help establish provenance, but they do not prove that signed code is safe; the signer and build process must also be trusted.

Dependency risk is not solved by blindly upgrading everything. Teams should determine whether a vulnerable component is present, reachable, exposed, exploitable in the deployed configuration, and mitigated by other controls. Emergency updates may be required, while routine upgrades should include compatibility testing.

8. Vulnerability Management and Remediation

A vulnerability program includes discovery, validation, prioritization, assignment, remediation, verification, and closure. Severity scores, such as those derived from CVSS, provide a common language but should not be used without environmental context. Internet exposure, exploit availability, affected data, compensating controls, and business criticality may change priority.

A practical remediation record contains the asset, component, evidence, affected versions, severity, owner, due date, treatment decision, workaround, and verification result. Possible treatments are remediation, mitigation, risk acceptance by an authorized owner, transfer, or retirement of the affected asset.

The goal is not merely to reduce the number of open findings. Useful measures include time to acknowledge, time to remediate by severity, recurrence rate, percentage of assets inventoried, and percentage of fixes verified. Metrics can be distorted if teams close findings without addressing root causes, so quality and recurrence should be examined.

9. Applied Case: Illustrative API Authorization Failure

Background

An illustrative online learning platform provides a mobile application and REST API. Students can view courses and download invoices. The endpoint GET /api/invoices/{invoiceId} authenticates users with a valid access token.

Problem

A code review finds that the endpoint retrieves an invoice using only invoiceId and returns it if the token is valid. The service does not verify that the invoice belongs to the authenticated student or the student’s organization. Invoice identifiers are not secret and can be obtained from normal responses.

Analysis

The asset is financial and personal information. The trust boundary lies between the client request and the API service. The threat is unauthorized object access, a form of broken object-level authorization. Authentication is present, but authentication alone does not establish permission for every object.

A threat-model abuse case is: “An authenticated student changes the invoice identifier and downloads another student’s invoice.” The impact includes privacy loss, regulatory exposure, and reputational damage. The risk is high because exploitation requires little skill and can be automated.

Approach and solution

The service should derive the user identity from the validated token and enforce authorization in the service layer. A conceptual database query is:

SELECT invoice
FROM invoices
WHERE invoice_id = requested_id
  AND owner_id = authenticated_user_id;

For organizational accounts, the service should additionally check organization membership, role, invoice status, and any delegated permissions. A generic not-found response can avoid revealing whether an unauthorized object exists, although error behavior must be designed consistently.

Tests should include valid ownership, another user’s identifier, another organization’s identifier, missing authentication, expired authentication, altered claims, and attempts through both mobile and direct API clients. Logging should record the authorization decision without exposing invoice contents or tokens.

Outcome

After remediation, the endpoint enforces object-level authorization, and regression tests remain in the pipeline. The organization also reviews other endpoints for the same pattern, adds an API authorization checklist to code review, and uses threat modeling for new resource APIs.

Learning points

1. A valid token does not imply permission to access every object.
2. Client-side restrictions are not security controls.
3. Authorization tests must include adversarial identifier changes.
4. Fixing one endpoint should trigger a search for related design defects.
5. Secure design, code review, testing, and monitoring reinforce one another.

10. Governance, Ethics, and Contemporary Practice

Security professionals have authority that can affect privacy, employment, finances, and public safety. Testing must be authorized, proportionate, documented, and conducted with safeguards. Responsible disclosure should provide affected parties enough information to reproduce and fix a vulnerability without unnecessarily enabling abuse.

Privacy principles include data minimization, purpose limitation, retention control, transparency, and appropriate protection of personal data. Regulatory obligations vary by jurisdiction and sector, but compliance should be treated as a baseline rather than proof of security.

Artificial intelligence can assist with code explanation, test generation, vulnerability triage, and detection of suspicious patterns. However, AI-generated code may contain insecure assumptions, hallucinated APIs, licensing concerns, or hidden data leakage. Developers must review generated code, avoid sending confidential source to unauthorized services, and test security properties independently. AI systems themselves require threat modeling, access control, data governance, prompt-injection defenses, and monitoring.

Contemporary practice increasingly emphasizes secure-by-design principles, memory-safe languages for suitable components, zero-trust service communication, software provenance, infrastructure-as-code security, runtime application protection, and continuous exposure management. These developments do not eliminate foundational requirements: least privilege, validation, authorization, secure dependency use, testing, and timely remediation remain central.

Best-Practice Checklist

• Define security requirements and abuse cases before implementation.
• Model assets, data flows, trust boundaries, and threats.
• Enforce authorization server-side for every sensitive action and object.
• Validate input and encode output according to context.
• Use parameterized queries and approved cryptographic libraries.
• Protect sessions, secrets, logs, and sensitive data.
• Review mobile clients as untrusted and APIs as directly callable.
• Combine automated tools with manual design and code review.
• Secure source repositories, build agents, pipeline credentials, and artifacts.
• Maintain an SBOM and monitor dependencies throughout their life cycle.
• Prioritize vulnerabilities using severity plus business and exposure context.
• Verify fixes and measure recurrence, not just ticket closure.
• Conduct authorized testing and protect privacy throughout the process.

Chapter Summary

Application security is a life-cycle discipline that protects web applications, mobile applications, APIs, code, data, and deployment systems. Effective security begins with threat modeling: identifying assets, trust boundaries, threats, abuse cases, and appropriate mitigations. Secure coding requires server-side validation, context-sensitive output encoding, parameterized queries, strong authentication, explicit authorization, protected sessions, sound cryptography, careful error handling, and privacy-aware logging.

No single security test is sufficient. SAST, SCA, secret scanning, DAST, IAST, manual review, and penetration testing reveal different classes of weakness. DevSecOps integrates these activities into CI/CD while protecting pipelines, credentials, artifacts, and environments. Supply-chain security requires dependency governance, SBOMs, provenance, integrity verification, and continuous monitoring. Vulnerability remediation should be risk-based, assigned, verified, and evaluated for recurrence.

Professional practice also requires authorization, ethical disclosure, privacy protection, regulatory awareness, and critical evaluation of emerging technologies such as AI. The central principle is continuous security improvement: secure design informs coding, coding informs testing, testing informs release decisions, and operational evidence informs the next design cycle.

Key Terms

Application security: Protection of software and its data against unauthorized or harmful actions.

API: An interface that enables software components to exchange data or invoke operations.

Authentication: Establishing the identity of a subject.

Authorization: Determining what an authenticated subject may do.

Broken object-level authorization: Failure to verify permission for a specific object requested through an API.

CI/CD: Continuous integration and continuous delivery or deployment practices for automated software delivery.

Defense in depth: Use of multiple independent or complementary security controls.

DevSecOps: Integration of security into development, operations, and automated delivery.

Dynamic application security testing: Testing a running application for security weaknesses.

Input validation: Checking data against expected type, structure, range, and business rules.

Least privilege: Granting only the permissions required for an authorized task.

OWASP: An open community and source of guidance, tools, and standards for application security.

SBOM: A software bill of materials listing components contained in a software product.

SAST: Static application security testing of source or compiled code.

SCA: Software composition analysis of dependencies and their known risks.

Threat modeling: Structured identification and analysis of threats and mitigations.

Trust boundary: A point where data crosses between different trust levels.

Vulnerability: A weakness that may be exploited to cause harm.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. What is a trust boundary, and why is it important in threat modeling?
3. State two reasons why mobile applications must not be treated as trusted clients.
4. What is the purpose of an SBOM?
5. Name three types of security testing and one limitation of each.

Long Answer Questions

1. Explain a complete threat-modeling process using a web application example.
2. Discuss secure coding practices for input validation, injection prevention, authentication, authorization, and session management.
3. Explain how DevSecOps changes the traditional relationship between development, security, and operations.
4. Compare SAST, SCA, DAST, IAST, manual review, and penetration testing.
5. Describe a risk-based vulnerability-remediation program, including prioritization, ownership, verification, and metrics.

Analytical / Application Questions

1. An API accepts a user identifier in the request body and returns that user’s profile when any valid token is supplied. Identify the vulnerability, explain the threat, and propose technical and testing controls.
2. A CI pipeline downloads unpinned third-party actions and uses a long-lived production credential. Analyze the supply-chain and pipeline risks and design a safer alternative.
3. A mobile banking application stores an API key in its binary and relies on client-side checks to restrict transfers. Evaluate the design and recommend a layered replacement architecture.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines identity; authorization determines permitted actions.

B. Authentication encrypts data; authorization compresses data.

C. Authentication records logs; authorization deletes logs.

D. Authentication validates input; authorization formats output.

Correct Answer: A. Authentication determines identity; authorization determines permitted actions.

Question 2

Which control most directly prevents SQL injection?

A. Hiding database error messages

B. Using parameterized queries

C. Increasing session timeout

D. Adding a client-side CAPTCHA

Correct Answer: B. Using parameterized queries

Question 3

Why must an API verify object ownership after validating a user token?

A. Tokens automatically expire after every request

B. Authentication does not prove permission to access every object

C. Object identifiers are always encrypted

D. Ownership checks are needed only for anonymous users

Correct Answer: B. Authentication does not prove permission to access every object

Question 4

Which activity is primarily associated with SCA?

A. Inspecting third-party dependencies for known vulnerabilities

B. Simulating a user’s interaction with a running application

C. Reviewing an employee’s security awareness

D. Encrypting database backups

Correct Answer: A. Inspecting third-party dependencies for known vulnerabilities

Question 5

Which item is a component of the STRIDE threat-modeling approach?

A. Serialization

B. Spoofing

C. Sharding

D. Sampling

Correct Answer: B. Spoofing

Question 6

Which practice best protects a CI/CD pipeline from excessive credential exposure?

A. Use one permanent administrator credential for all jobs

B. Store credentials in source code for auditability

C. Use short-lived, least-privilege credentials

D. Allow every pull request to access production secrets

Correct Answer: C. Use short-lived, least-privilege credentials

Question 7

What is the primary purpose of output encoding?

A. To ensure data is interpreted safely in its output context

B. To increase database storage capacity

C. To replace multifactor authentication

D. To guarantee that dependencies contain no vulnerabilities

Correct Answer: A. To ensure data is interpreted safely in its output context

Question 8

Which statement about mobile application security is correct?

A. A secret embedded in a mobile binary should be considered inaccessible to attackers

B. Client-side authorization is sufficient if the official app is distributed through a trusted store

C. Backend services should enforce authorization because mobile clients can be modified

D. Obfuscation guarantees that reverse engineering is impossible

Correct Answer: C. Backend services should enforce authorization because mobile clients can be modified

Question 9

Which remediation activity provides evidence that a vulnerability fix works?

A. Deleting the vulnerability ticket without testing

B. Repeating an appropriate security test after the change

C. Changing the vulnerability’s title

D. Moving the affected system to a different project

Correct Answer: B. Repeating an appropriate security test after the change

Question 10

Why is defense in depth valuable in application security?

A. It ensures that one failed control cannot automatically cause total compromise

B. It removes the need for secure coding

C. It guarantees that every vulnerability is detected automatically

D. It allows organizations to avoid authorization decisions

Correct Answer: A. It ensures that one failed control cannot automatically cause total compromise