Application, Web, API, and Data Vulnerabilities

Introduction

Modern organisations depend on web applications, mobile applications, application programming interfaces (APIs), cloud services, and databases. These systems process identity information, financial records, intellectual property, health data, and operational commands. Their security therefore depends not only on network controls but also on the design and implementation of the software itself.

Application vulnerabilities arise when software permits an unintended action, exposes information improperly, or fails to enforce a security requirement. The weakness may result from insecure architecture, defective code, unsafe configuration, poor authentication, inadequate cryptography, or an exposed database. The Open Worldwide Application Security Project (OWASP) provides widely used guidance for identifying and reducing these risks. The OWASP Top 10 is an awareness document rather than a complete vulnerability catalogue; it should be used with secure-development practices, threat modelling, testing, and operational monitoring.

This chapter introduces major application, web, API, and data vulnerabilities at certificate level. It focuses on the underlying security principles, common attack conditions, practical prevention, and the responsibilities of developers, testers, system administrators, and security professionals.

Learning Objectives

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

• explain how insecure design differs from an implementation defect;
• describe injection, cross-site scripting, and broken access control;
• explain cryptographic failures and insecure handling of sensitive data;
• identify common API and software vulnerabilities;
• describe how databases become exposed and how exposure can be reduced;
• apply secure-development principles to a practical application scenario; and
• recommend appropriate preventive, detective, and corrective controls.

1. Security Foundations for Applications

Assets, threats, vulnerabilities, and risk

An asset is something requiring protection, such as a customer record, password, payment token, service, or business process. A threat is a potential cause of harm, while a vulnerability is a weakness that can be exploited. Risk describes the possibility and consequence of an adverse event. A simple qualitative model is:

Likelihood and impact are not necessarily precise numerical values. The expression is a reasoning aid: a highly exploitable weakness affecting critical data deserves greater attention than a weakness with negligible consequences.

The principal security objectives are confidentiality, integrity, and availability. Authentication establishes who a user or service is. Authorisation determines what that identity may do. Accountability connects actions to identities through reliable logging and monitoring.

Secure-development principles

Secure software is produced through a lifecycle rather than by a final security test. Important principles include:

• Least privilege: grant only the permissions required for a task.
• Deny by default: access is rejected unless an explicit rule permits it.
• Complete mediation: check authorisation every time a protected resource is accessed.
• Defence in depth: use multiple independent safeguards.
• Fail securely: errors should not disclose secrets or grant access.
• Secure defaults: initial configurations should be safe.
• Input validation: accept only data that conforms to an expected format and context.
• Separation of duties: divide sensitive responsibilities to reduce abuse and error.
• Psychological acceptability: security controls should be usable enough that people do not bypass them.

A secure lifecycle integrates requirements, threat modelling, design review, coding standards, dependency management, testing, deployment controls, monitoring, and incident response.

2. Insecure Design

Insecure design is a weakness in architecture, workflow, or business logic. It exists even when the code correctly implements the flawed design. For example, an online examination system that allows unlimited password-reset attempts has a design problem if the requirement never considered account takeover. Similarly, an application that permits a user to approve their own high-value transaction violates separation of duties.

Implementation weaknesses are different. A design may require authorisation checks, but a programmer may omit a check in one endpoint. That is a coding or implementation defect. The distinction matters because insecure design cannot be solved only by patching individual lines of code; the security requirement and system workflow must be reconsidered.

Threat modelling

Threat modelling is a structured method for asking what can go wrong, who may cause it, what assets are affected, and which controls are appropriate. A basic process is:

1. identify assets and trust boundaries;
2. document users, services, data flows, and entry points;
3. identify threats and abuse cases;
4. estimate likelihood and impact;
5. select preventive and detective controls; and
6. validate the design through review and testing.

The STRIDE model is one useful classification approach: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. It is a prompt for analysis, not a substitute for understanding the particular system.

Design controls

Effective controls include rate limits, transaction limits, multi-person approval, secure recovery processes, explicit state transitions, segregation of administrative functions, and privacy-preserving defaults. Business rules must be enforced on the server because client-side controls can be modified or bypassed.

3. Injection Vulnerabilities

Injection occurs when untrusted input is interpreted as part of a command or query. Common forms include SQL injection, operating-system command injection, LDAP injection, and template injection. The underlying error is a failure to separate data from instructions.

For example, an unsafe database operation may construct a query by joining a username directly into a string. If an attacker supplies database syntax instead of an ordinary username, the database may interpret that input as instructions. The consequences can include unauthorised reading, modification, deletion, authentication bypass, or in some environments further compromise.

Prevention

The preferred SQL control is a parameterised query, in which the SQL structure is defined separately from the values supplied by the user. Object-relational mapping tools can help, but they do not automatically make every operation safe. Developers must also avoid unsafe raw-query functions and verify that parameters are actually bound.

Additional controls include:

• allow-list validation for structured input;
• least-privilege database accounts;
• stored procedures designed safely;
• separation of application and administrative database accounts;
• safe error handling; and
• security testing with representative inputs.

Escaping is context-dependent and is not a universal replacement for parameterisation. Input validation is useful, but validation alone cannot reliably prevent every injection condition.

4. Cross-Site Scripting

Cross-site scripting (XSS) occurs when an application causes a user's browser to execute attacker-controlled script in the security context of a trusted site. XSS can be classified as:

• Reflected XSS: malicious content is returned immediately in a response, often through a request parameter.
• Stored XSS: malicious content is saved by the application and later displayed to other users.
• DOM-based XSS: client-side JavaScript processes unsafe data and creates the vulnerability in the browser.

The impact may include account actions performed through the victim's session, theft of accessible page data, alteration of displayed content, or redirection to fraudulent pages. HttpOnly cookies reduce direct script access to cookies, but they do not eliminate all XSS impact.

Prevention

The primary control is context-sensitive output encoding. Data placed in HTML text, an HTML attribute, JavaScript, CSS, or a URL requires the encoding appropriate to that context. Trusted templating frameworks often provide automatic escaping, but developers must avoid unsafe features that interpret data as markup or code.

Other controls include:

• sanitising user-supplied rich text with a well-maintained library;
• using a restrictive Content Security Policy where practical;
• validating input according to business requirements;
• setting cookies with Secure, HttpOnly, and appropriate SameSite attributes; and
• testing both server-side and client-side rendering paths.

XSS is not the same as SQL injection. XSS targets an interpreter in the browser, while SQL injection targets a database interpreter. The common principle is nevertheless identical: keep data separate from executable instructions.

5. Broken Access Control

Broken access control occurs when users can perform actions or access resources beyond their authorised permissions. Examples include viewing another customer's invoice by changing an identifier, calling an administrative endpoint as an ordinary user, or modifying a record after authorisation was checked only in the user interface.

A useful distinction is:

• horizontal privilege escalation: one user accesses another user's resources; and
• vertical privilege escalation: a lower-privileged user performs a higher-privileged action.

Insecure direct object references are a common symptom. An identifier in a URL or request is not itself an authorisation decision. The server must determine whether the authenticated subject is permitted to access the referenced object.

Prevention and verification

Applications should centralise and consistently enforce authorisation policies on the server. Each protected operation should verify the subject, action, object, and relevant context. Policies should deny by default and should be tested for both permitted and prohibited cases.

Useful controls include opaque or unpredictable identifiers where appropriate, object-level ownership checks, role and attribute-based policies, administrative separation, and logging of denied access. Changing an identifier, HTTP method, or request format should not bypass a policy.

6. Cryptographic Failures and Sensitive Data

Cryptographic failures occur when sensitive information is not protected appropriately during storage, transmission, processing, or disposal. Common examples include transmitting credentials over unencrypted connections, storing passwords as reversible encryption, using obsolete algorithms, exposing encryption keys in source code, and retaining sensitive data unnecessarily.

Passwords

Passwords should normally be stored using a password-hashing function designed to resist offline guessing, such as Argon2id, scrypt, or bcrypt, configured according to current operational guidance. A password hash is not encryption: it is intended to be computationally difficult to reverse. Each password should have a unique salt, which prevents identical passwords from producing identical stored values and reduces the value of precomputed tables.

Encryption is appropriate when authorised systems must recover the original data. Encryption requires sound key management, including generation, protection, rotation, access control, backup, and revocation. Keeping a key beside the ciphertext in the same unprotected location provides little effective protection.

Transport and data minimisation

TLS should protect data in transit, with certificate validation and secure protocol configuration. Sensitive information should be classified, collected only when necessary, retained for a justified period, and securely deleted when no longer required. Logs, error messages, backups, analytics systems, and test environments must be considered because they frequently become secondary sources of exposure.

Cryptography does not correct an access-control flaw. A database encrypted at rest can still disclose all records if an attacker obtains a legitimate application credential with excessive privileges.

7. Insecure APIs

An API is a defined interface through which software components exchange requests and responses. APIs may be RESTful, GraphQL-based, event-driven, or based on other protocols. Because APIs directly expose functions and data, they require explicit security design.

Common API weaknesses include:

• missing or weak authentication;
• broken object-level authorisation;
• excessive data returned in responses;
• unrestricted property or field modification;
• inadequate rate limiting;
• unsafe consumption of third-party APIs;
• poor validation of content type, size, and structure;
• verbose error messages; and
• outdated or undocumented endpoints.

An API gateway can provide useful functions such as authentication integration, rate limiting, routing, and monitoring, but it does not replace authorisation inside the service that owns the data. A service must not trust a client merely because the request passed through a gateway.

API security practices

Document endpoints, data types, authentication requirements, error behaviour, and authorisation rules. Validate request bodies and query parameters against an explicit schema. Return only the fields required by the client. Apply rate limits based on the risk and business function, and use stronger controls for password recovery, payment, and administrative operations.

Tokens should have limited scope, lifetime, and audience. Secrets must not be placed in URLs because URLs may be stored in browser history, proxy logs, and analytics systems. APIs should be versioned and retired endpoints should be removed or protected.

8. Software and Dependency Flaws

Software can be vulnerable because of defective application code, insecure libraries, vulnerable operating-system packages, unsafe build processes, or unsupported components. A dependency is not secure merely because it is popular or included in a package repository.

A software inventory or software bill of materials (SBOM) helps identify components and versions. Dependency management should include trusted sources, version pinning or controlled update ranges, vulnerability monitoring, timely patching, and review of transitive dependencies. Automated tools are valuable but produce false positives and false negatives; findings require human assessment.

Secure coding practices include bounds checking, safe memory handling, predictable error behaviour, correct concurrency controls, and avoidance of dangerous deserialisation. Developers should review compiler and interpreter warnings, use static analysis appropriately, and test security-relevant paths.

The build pipeline is part of the attack surface. Source repositories, build servers, signing keys, package registries, and deployment credentials require strong access control and monitoring. A compromised development dependency can affect many downstream users, making software supply-chain security an organisational responsibility.

9. Database Exposure and Data Security

Database exposure occurs when data becomes accessible to unauthorised parties. Causes include public network exposure, weak credentials, excessive privileges, injection, insecure backups, exposed administrative interfaces, misconfigured cloud storage, unencrypted exports, and sensitive data in development environments.

Layered database protection

A secure database architecture commonly includes:

1. network segmentation and restricted inbound access;
2. private administrative interfaces and controlled management paths;
3. separate accounts for applications, reporting, migration, and administration;
4. least-privilege permissions;
5. parameterised queries and safe stored procedures;
6. encryption in transit and at rest where appropriate;
7. monitored backups with tested restoration;
8. logging of privileged and unusual activity; and
9. retention and deletion rules.

A backup is not automatically secure because it is stored away from production. It may contain a complete copy of sensitive information and therefore needs equivalent access control, encryption, monitoring, and disposal.

Data masking, tokenisation, and anonymisation can reduce exposure in testing and analytics. However, masking must be assessed against re-identification risk; removing obvious names does not necessarily make a dataset anonymous.

10. Applied Case: The HorizonCare Patient Portal

Background

HorizonCare, a fictional regional healthcare provider, launches a patient portal. Patients can view appointments, download reports, send messages, and update contact details. A mobile application communicates with a set of web APIs. The initial release passes functional testing but has limited security testing.

Problem

A security review identifies four findings. First, a report endpoint accepts a patient identifier supplied by the client and does not verify ownership. Second, a search field displays stored comments without proper output encoding. Third, the application constructs a reporting query by concatenating a filter parameter. Fourth, database backups are copied to a cloud storage location accessible through a broadly shared administrative credential.

Analysis

The first weakness is broken object-level authorisation and could permit horizontal privilege escalation. The second is stored XSS and could affect staff members who review patient comments. The third is injection because data is being interpreted as SQL syntax. The fourth is database exposure caused by excessive privilege and poor backup governance. These weaknesses interact: a compromised staff session or exposed backup could cause severe confidentiality and integrity consequences.

Approach and solution

The organisation first restricts access to the affected endpoints and rotates exposed credentials. Developers change the report query to use parameters and create a dedicated reporting account with read-only, limited permissions. The API now derives the patient identity from the authenticated session and checks object ownership on every request. Stored comments are encoded according to their output context, and the portal uses a carefully designed Content Security Policy.

The backup process is redesigned with private storage, encryption, separate service identities, short-lived credentials, restricted administrative access, and restoration testing. The team adds threat modelling to the development process, security-focused code review, dependency scanning, API schema validation, logging, and tests for unauthorised object access.

Outcome

The immediate vulnerabilities are remediated, but the more important outcome is process improvement. Security requirements are added to feature planning, and the organisation establishes an incident-response procedure for suspected data exposure. Periodic access reviews verify that staff and service accounts retain only necessary permissions.

Learning points

• A user-interface restriction is not an access-control mechanism.
• API endpoints must enforce object-level permissions on the server.
• Parameterisation protects the boundary between data and SQL instructions.
• Output encoding must match the context in which data is displayed.
• Backups, logs, and cloud storage are part of the data-security boundary.
• Technical remediation should be combined with lifecycle, governance, and monitoring improvements.

11. Testing, Governance, and Professional Practice

Security testing should combine several techniques. Static application security testing examines source or compiled code. Dynamic testing evaluates a running application. Software composition analysis identifies dependency risks. Manual review is essential for business logic and authorisation because automated tools may not understand organisational rules.

Testing must be authorised and carefully scoped. Security professionals should avoid accessing real personal data unnecessarily, protect test evidence, and report vulnerabilities responsibly. Production testing can create outages or alter records; test environments and synthetic data are preferable where possible.

Organisations should align application security with applicable privacy, breach-notification, payment, health, or sector-specific obligations. Compliance is not identical to security. A system may satisfy a checklist and remain vulnerable to a novel business-logic flaw. Governance should therefore assign ownership, define risk-acceptance authority, track remediation, and measure whether controls operate effectively.

Artificial intelligence can assist code review, log analysis, test generation, and vulnerability triage. However, generated code may contain insecure assumptions, disclose confidential source material, or reproduce flawed patterns. AI outputs require review, testing, licensing consideration, and human accountability. AI systems themselves introduce application risks, including prompt injection, insecure tool use, data leakage, and excessive autonomy.

12. Practical Secure-Development Checklist

Before release, a team should be able to answer yes to questions such as:

• Have assets, trust boundaries, threats, and abuse cases been identified?
• Are authentication and authorisation enforced server-side?
• Are database queries parameterised?
• Is output encoded or safely sanitised for its context?
• Are passwords hashed with a suitable password-hashing function?
• Is sensitive data minimised, encrypted where appropriate, and excluded from unnecessary logs?
• Are API schemas, rate limits, response fields, and error messages reviewed?
• Are dependencies inventoried, supported, and monitored?
• Are database accounts, backups, and cloud resources least-privileged and monitored?
• Have both successful and prohibited actions been tested?
• Are security findings assigned, prioritised, remediated, and retested?

No checklist guarantees secure software. It provides a repeatable baseline that must be adapted to the system's assets, threats, technology, and legal context.

Chapter Summary

Application security concerns the software, interfaces, data stores, development process, and operational environment that together deliver a service. Insecure design originates in flawed requirements or architecture, whereas implementation vulnerabilities arise when a sound requirement is incorrectly coded. Injection results from mixing data with commands; parameterised queries and context-appropriate validation reduce this risk. XSS enables attacker-controlled content to execute in a user's browser and is primarily addressed through context-sensitive output encoding and safe rendering.

Broken access control occurs when an application fails to enforce permissions for an action or object. It must be addressed through server-side, deny-by-default, repeated authorisation checks. Cryptographic failures involve inappropriate protection, storage, transmission, key management, or retention of sensitive information. APIs require explicit authentication, object-level authorisation, schema validation, limited responses, rate control, and lifecycle management. Software dependencies, build systems, backups, cloud storage, and databases are all part of the application attack surface.

Secure development is continuous. Threat modelling, least privilege, secure defaults, code review, automated and manual testing, monitoring, governance, and responsible incident response provide defence in depth. The fictional HorizonCare case demonstrates that vulnerabilities often combine across application, API, database, and operational boundaries.

Key Terms

Asset: A resource or information requiring protection.

Authentication: The process of establishing an identity.

Authorisation: The process of deciding whether an identity may perform an action.

Broken access control: Failure to enforce intended permissions.

Cross-site scripting (XSS): Injection of attacker-controlled script into a trusted web context.

Database exposure: Unauthorised access to database contents or administrative functions.

Defence in depth: Use of multiple complementary security controls.

Encryption: Transformation of readable data into ciphertext using a key.

Horizontal privilege escalation: Access to another user's resources at the same privilege level.

Injection: Manipulation of an interpreter through untrusted input.

Insecure design: A security weakness in requirements, architecture, or workflow.

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

Object-level authorisation: Checking permission to access a particular resource.

Parameterised query: A database query that separates command structure from values.

Password hashing: One-way, computationally costly processing used to store password verifiers.

Secure development lifecycle: Integration of security activities throughout software development.

Threat modelling: Structured analysis of assets, trust boundaries, threats, and controls.

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

Vertical privilege escalation: Performance of higher-privilege actions by a lower-privilege identity.

Review Questions

Short Answer Questions

1. What is the difference between insecure design and an implementation vulnerability?
2. Why are parameterised queries preferred to string concatenation for SQL operations?
3. Distinguish reflected, stored, and DOM-based XSS.
4. What is broken object-level authorisation?
5. Why must backups receive security controls similar to production databases?

Long Answer Questions

1. Explain the secure-development principles of least privilege, deny by default, complete mediation, and defence in depth, using application examples.
2. Describe the causes, impacts, and prevention methods for injection vulnerabilities.
3. Explain how cryptographic failures can arise in password storage, data transmission, key management, and data retention.
4. Discuss the main security requirements for a public API, including authentication, authorisation, validation, rate limiting, and error handling.
5. Explain how threat modelling can identify insecure design before software implementation begins.

Analytical / Application Questions

1. An API allows a logged-in customer to request /orders/1842 by changing the order number in the URL. Analyse the vulnerability and propose server-side controls and tests.
2. A development team stores production database backups in a shared cloud folder and uses one administrator account for all services. Assess the risks and design a safer arrangement.
3. A comment field accepts formatting and is later displayed in a staff dashboard. Develop a risk-based plan covering input handling, output encoding, browser controls, testing, monitoring, and incident response.

Multiple Choice Questions with Answers

Question 1

Which control most directly prevents SQL injection?

A. Parameterised queries

B. Increasing screen brightness

C. Disabling browser cookies

D. Adding more database replicas

Correct Answer: A. Parameterised queries

Question 2

A user changes an object identifier and views another customer's invoice. What vulnerability is most directly demonstrated?

A. Stored XSS

B. Broken object-level authorisation

C. Weak encryption

D. Denial of service

Correct Answer: B. Broken object-level authorisation

Question 3

Which practice is most appropriate for storing passwords?

A. Reversible encryption with a shared application key

B. Plaintext storage in a protected table

C. A suitable password-hashing function with a unique salt

D. Base64 encoding

Correct Answer: C. A suitable password-hashing function with a unique salt

Question 4

What is the primary purpose of output encoding in web applications?

A. To increase database capacity

B. To prevent data from being interpreted as executable content in its output context

C. To replace authentication

D. To create stronger passwords

Correct Answer: B. To prevent data from being interpreted as executable content in its output context

Question 5

Which statement best describes insecure design?

A. A typographical error in documentation

B. A weakness in requirements, architecture, or workflow

C. A correctly configured firewall

D. A routine software update

Correct Answer: B. A weakness in requirements, architecture, or workflow

Question 6

Why should an API return only necessary fields?

A. To reduce excessive data exposure

B. To eliminate the need for authorisation

C. To make all requests anonymous

D. To disable logging

Correct Answer: A. To reduce excessive data exposure

Question 7

Which principle requires permissions to be checked whenever a protected resource is accessed?

A. Complete mediation

B. Data minimisation

C. Obfuscation

D. Portability

Correct Answer: A. Complete mediation

Question 8

Which item is part of software supply-chain security?

A. Ignoring transitive dependencies

B. Maintaining an inventory of software components

C. Sharing build credentials publicly

D. Disabling all software updates

Correct Answer: B. Maintaining an inventory of software components

Question 9

Which control best reduces the impact of a compromised application database account?

A. Giving the account unrestricted administrator privileges

B. Using a least-privilege account limited to required operations

C. Removing all database logs

D. Storing credentials in source code

Correct Answer: B. Using a least-privilege account limited to required operations

Question 10

What is a key limitation of automated vulnerability scanners?

A. They can never inspect network traffic

B. They may miss business-logic and context-dependent authorisation flaws

C. They always alter production data

D. They make manual review illegal

Correct Answer: B. They may miss business-logic and context-dependent authorisation flaws