Data, Application and API Security

Introduction and Context

Modern organisations depend on information systems that collect, process, exchange and retain data through web applications, mobile applications, microservices and application programming interfaces (APIs). Security failures in any of these components can expose confidential information, alter business records, interrupt services or provide attackers with a path into wider organisational networks.

Data, application and API security are therefore closely related disciplines. Data security protects information itself; application security reduces weaknesses in software that handles information; and API security protects the interfaces through which applications and services communicate. Effective protection requires controls throughout the information lifecycle rather than reliance on a single perimeter device or security product.

This chapter presents a lifecycle-based approach to protecting information, explains common web and application risks, examines API-specific threats, and connects secure coding with OWASP guidance and DevSecOps practices.

Learning Objectives

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

• classify information according to sensitivity, value and regulatory obligations;
• select appropriate encryption, access-control, data-loss-prevention and retention controls;
• explain secure disposal and the limits of deletion in modern systems;
• identify common web application, software supply-chain and API risks;
• apply relevant OWASP principles to design, development, testing and operation;
• distinguish authentication, authorisation and accountability;
• design practical security controls for APIs and microservices;
• integrate security into a DevSecOps lifecycle; and
• evaluate technical, ethical, governance and operational trade-offs.

1. Information as an Asset

Information has value because it supports decisions, transactions, service delivery, legal compliance and competitive advantage. Its security requirements depend on its characteristics and context. A public marketing brochure does not require the same protection as a medical record, cryptographic key or unreleased acquisition plan.

The central security objectives are confidentiality, integrity and availability (CIA):

• Confidentiality means that information is disclosed only to authorised people, processes or systems.
• Integrity means that information remains accurate, complete and protected from unauthorised modification.
• Availability means that authorised users can access information and services when required.

Additional properties are often essential. Authenticity establishes that an entity or message is genuine. Accountability links actions to responsible identities through reliable logging. Non-repudiation provides evidence that a party performed an action, although technical evidence alone cannot resolve every legal dispute.

Information classification

Classification is a business decision supported by security analysis. A useful four-level model is shown below.

A classification scheme should define ownership, permitted processing, storage locations, sharing rules, retention period, incident response expectations and disposal method. Labels are useful only when systems enforce them. A document labelled “Restricted” but freely downloadable by all employees is not effectively protected.

Classification should be reviewed when the information changes state. A preliminary design may be confidential, become public after an approved announcement, and later become subject to retention or archival requirements. Data inventories, records of processing, discovery tools and asset registers help organisations locate copies and identify owners.

2. Protecting Data Throughout Its Lifecycle

The information lifecycle commonly includes creation or collection, use, sharing, storage, archival and destruction. Controls should be selected according to threats at each stage.

Figure: Information lifecycle and representative security controls.

Encryption

Encryption transforms plaintext into ciphertext using an algorithm and a key. It protects confidentiality when correctly implemented, but it does not by itself establish that data is accurate, that a user is authorised, or that a system is available.

• Encryption in transit protects communications between clients, services and administrators. TLS should be configured using current, supported versions and strong cipher suites. Certificate validation is essential; simply using HTTPS without validating certificates does not provide reliable authentication.
• Encryption at rest protects databases, disks, backups and removable media. Full-disk encryption is valuable if a device is lost, but application-level or field-level encryption may be necessary when storage administrators should not see particular values.
• End-to-end or application-level encryption can reduce exposure to intermediate systems, although it increases key-management complexity.

Symmetric encryption uses the same secret key for encryption and decryption and is efficient for large data volumes. Public-key cryptography uses a public/private key pair and supports key exchange and digital signatures, but is generally more computationally expensive. Modern protocols combine both approaches: public-key techniques establish or protect a session key, while symmetric encryption protects the data stream.

Authenticated encryption, such as AES-GCM or ChaCha20-Poly1305 when correctly implemented, provides confidentiality and integrity. Nonces or initialization vectors must be unique under the relevant key; reuse can seriously compromise security. Passwords should not be encrypted for later recovery. They should be processed using a slow, memory-hard password hashing scheme such as Argon2id, with a unique salt and a policy appropriate to the threat environment.

Key management

The security of encrypted data depends on key management. Organisations should generate keys using approved cryptographic random sources, restrict key access, separate duties, rotate keys according to risk, maintain backup and recovery procedures, and revoke compromised keys. Keys should not be embedded in source code, container images or public repositories. A hardware security module or managed key-management service can protect high-value keys, but it does not remove the need for sound authorisation and operational procedures.

Access control

Access control answers three questions: who or what is requesting access, what operation is requested, and whether that operation is permitted on the resource. Authentication establishes identity; authorisation determines permissions; accounting records relevant activity.

The principle of least privilege grants only the access necessary for an approved task. This should be combined with separation of duties, deny-by-default policies, just-in-time privilege for sensitive actions, periodic access reviews and rapid removal of departed users. Role-based access control assigns permissions to roles, while attribute-based access control can use attributes such as department, location, device trust, data classification and time.

Insecure direct object references occur when an application accepts an object identifier and fails to verify that the current user may access that object. The remedy is server-side authorisation on every request, not merely hiding identifiers in the user interface. Predictable or random identifiers do not replace authorisation checks.

Data loss prevention and privacy

DLP controls attempt to detect and prevent inappropriate transfer of sensitive information through email, web uploads, endpoints, cloud storage or removable media. Techniques include pattern matching, exact data matching, document fingerprints, labels and contextual analysis. DLP can produce false positives and may encourage unsafe workarounds, so policies should be risk-based and accompanied by user education and an appeal process.

Privacy requires more than secrecy. Organisations should collect only necessary information, define a lawful purpose, limit secondary use, provide appropriate transparency, support individual rights where applicable, and protect data shared with processors. Security monitoring should be proportionate and governed; employees and customers should not be subjected to unnecessary surveillance.

Retention and secure disposal

Retention schedules specify how long records should be kept and when they should be destroyed. Retention may be required by law, contract, litigation hold, audit needs or operational necessity. Keeping data indefinitely increases breach impact, discovery costs and privacy risk. A legal hold may suspend ordinary disposal, so destruction processes must check for holds before execution.

Deletion from an application is not always physical erasure. Copies may remain in backups, replicas, caches, logs, search indexes, snapshots and third-party systems. Disposal controls should therefore cover the complete data map. Depending on media and sensitivity, methods include cryptographic erasure, verified overwriting, degaussing where appropriate, and physical destruction by a controlled provider. Evidence such as destruction certificates and audit records supports accountability, but organisations should avoid claiming perfect erasure when immutable backups or technical limitations prevent it.

3. Web and Application Security

Application security is a continuous discipline covering requirements, architecture, implementation, dependencies, testing, deployment and operation. The familiar “shift left” idea is useful because early design corrections are cheaper than emergency remediation, but security must not be shifted left so far that operational monitoring and incident response are neglected.

Common application weaknesses

The OWASP Top 10 is an awareness document rather than a complete security standard. Its categories have included risks such as broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, identification and authentication failures, software and data integrity failures, logging and monitoring failures, and server-side request forgery. Organisations should use the current OWASP material and supplement it with threat modelling, secure standards and testing appropriate to their systems.

Injection occurs when untrusted data changes the meaning of an interpreter command. SQL injection, command injection and cross-site scripting are examples. Parameterised queries, context-sensitive output encoding, safe APIs, allow-list validation and avoiding shell interpretation are stronger controls than trying to remove a few suspicious characters.

Cross-site request forgery (CSRF) abuses a browser’s authenticated context to make an unwanted state-changing request. Anti-CSRF tokens, SameSite cookie controls and origin checks can reduce risk. CSRF protection is distinct from protection against cross-site scripting (XSS), in which attacker-controlled script executes in a victim’s browser. Context-appropriate output encoding, content security policy and safe templating help mitigate XSS.

Security misconfiguration includes default credentials, unnecessary services, permissive cloud storage, verbose production errors, missing security headers and inconsistent environments. Secure baseline configurations, automated checks and configuration management are required because manual inspection does not scale.

Identification and authentication failures include weak passwords, credential stuffing, insecure session handling, poor recovery workflows and missing multi-factor authentication. Sessions require unpredictable identifiers, secure and appropriately scoped cookies, expiration, revocation after sensitive events and protection against fixation.

Software supply-chain risk arises from vulnerable libraries, malicious packages, compromised build systems, unsafe update mechanisms and unverified artifacts. Dependency inventories, software bills of materials, signed builds, provenance checks, version pinning with controlled updates and vulnerability response processes reduce exposure.

Secure coding practices

Secure coding begins with requirements that identify assets, trust boundaries, abuse cases and failure consequences. Developers should validate input according to expected type, length, range and format, but validation is not a substitute for output encoding or authorisation. Errors should fail safely without exposing secrets, stack traces or internal topology. Secrets belong in managed secret stores, not logs or repositories.

Security-relevant code should be reviewed by people who understand both business logic and attack techniques. Tests should include positive, negative, boundary and abuse cases. Static application security testing (SAST) examines source or intermediate code; dynamic application security testing (DAST) tests running systems; interactive testing combines runtime observation with code context; and software composition analysis (SCA) examines dependencies. Each method has blind spots, so a mature programme uses them together with manual review and penetration testing.

4. API Security

An API is a contractual interface through which software requests data or actions. REST APIs commonly use HTTP methods and JSON, while GraphQL, gRPC, event interfaces and legacy SOAP services have different security characteristics. API security must protect both the interface and the underlying business operation.

API security principles

1. Inventory and ownership: Record every production, test, partner and deprecated endpoint. Unknown “shadow APIs” cannot be governed reliably.
2. Strong authentication: Use appropriate mechanisms such as mutual TLS for service identity, OAuth 2.0 for delegated access, or signed tokens where their lifecycle is managed correctly. API keys identify an application or client but are usually weaker than user authentication and should not be treated as universal authorisation.
3. Explicit authorisation: Check resource-level, function-level and property-level permissions on the server. A valid token does not imply permission to every object or field.
4. Input and output control: Validate schemas, types, sizes, content types and permitted values. Return only fields required by the consumer; excessive data exposure is a design failure.
5. Abuse resistance: Apply rate limits, quotas, pagination, concurrency controls and anomaly detection. Limits should reflect business needs and should not become a denial-of-service mechanism against legitimate users.
6. Transport and message protection: Use TLS, protect tokens, prevent replay where necessary, and apply message signing or encryption when intermediaries are not trusted.
7. Lifecycle management: Version APIs deliberately, document deprecation, revoke credentials, rotate secrets and remove obsolete endpoints.
8. Observability: Log identity, endpoint, outcome, correlation identifier and relevant object reference without recording passwords, access tokens or unnecessary personal data.

The OWASP API Security Top 10 highlights risks including broken object-level authorisation, broken authentication, excessive data exposure, lack of resources and rate limiting, broken function-level authorisation, unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration, improper inventory management and unsafe consumption of APIs. These categories emphasise that API security is often a business-logic problem, not merely a gateway configuration problem.

Tokens and OAuth considerations

A bearer token grants access to whoever possesses it, so transport protection, short lifetimes, audience restrictions, secure storage and revocation strategy matter. JWTs should be validated for signature, issuer, audience, expiry, acceptable algorithm and relevant claims. A JWT is not automatically encrypted; signing provides integrity and authentication of the issuer, while encryption provides confidentiality.

OAuth 2.0 is an authorisation framework, not a complete identity protocol. OpenID Connect adds an identity layer. Implementations must use the correct flow for the client type, protect redirect URIs, use state and nonce protections where applicable, and avoid placing access tokens in URLs. Detailed implementation should follow current standards and provider guidance rather than copying informal examples.

5. DevSecOps and Security Governance

DevSecOps integrates security into the development and operations flow while retaining human risk judgement. A practical pipeline may include:

• requirements and threat modelling;
• secure design patterns and approved components;
• pre-commit secret scanning and linting;
• SAST and dependency analysis during build;
• infrastructure-as-code and container configuration checks;
• automated tests in a security test environment;
• controlled deployment with signed artifacts and separation of duties;
• runtime monitoring, vulnerability management and incident response; and
• feedback into requirements and engineering standards.

Automation should produce actionable findings. Blocking every low-confidence scanner alert causes alert fatigue, whereas ignoring critical findings creates unacceptable risk. A risk-based policy can define severity thresholds, exploitability, exposure, compensating controls, remediation deadlines and exception approval. Exceptions should have an owner, expiry date and documented rationale.

Security champions embedded in development teams can improve communication, but responsibility remains shared among product owners, architects, developers, operations, security specialists and leadership. Governance should define security objectives, acceptable risk, evidence requirements, third-party obligations and reporting metrics. Useful measures include remediation time by severity, percentage of services with an inventory, unresolved critical vulnerabilities, MFA coverage, secrets detected in repositories, authorisation test coverage and incidents caused by known weaknesses. Metrics should support decisions rather than reward superficial compliance.

6. Applied Case: Illustrative Online Health-Services API

Background

A fictional health-services provider operates a patient portal and mobile application. The portal exposes appointment, prescription and billing APIs. A rapid development programme introduced several microservices, a cloud data store and multiple external partners.

Problem

An internal review found that a patient could alter an appointment identifier in a request and retrieve another patient’s appointment. The API gateway enforced TLS and checked that a token was valid, but the appointment service did not verify ownership. Logs also contained access tokens, old test endpoints remained publicly reachable, and backups were retained indefinitely.

Analysis

The central failure was broken object-level authorisation. The organisation confused authentication at the gateway with authorisation in the service. Additional weaknesses involved sensitive logging, inadequate API inventory and uncontrolled retention. Encryption in transit reduced interception risk but did not prevent an authenticated user from requesting another person’s record.

Approach and solution

The provider first disabled the vulnerable endpoint and reviewed access logs for possible misuse. It then implemented server-side authorisation based on the authenticated patient identity and the appointment’s owning record. Authorisation tests were added for horizontal access attempts, administrative functions and field-level disclosure. The provider created an API inventory, removed obsolete endpoints, introduced schema validation and pagination, and applied quotas based on documented service requirements.

Tokens were removed from logs and a controlled token-revocation process was established. Sensitive records were encrypted at rest with keys held in a managed key service. Backup retention was aligned with legal and clinical requirements, while legal holds were integrated into disposal workflows. Threat modelling and security tests became release gates for high-risk changes, and an incident-response exercise tested notification and evidence-preservation procedures.

Outcome

The provider reduced unauthorised data exposure risk, improved visibility of its API estate and made retention defensible. It did not treat the gateway as a complete solution; controls were placed at the service and data layers where business decisions occur.

Learning points

• Valid authentication does not prove resource ownership.
• Encryption cannot compensate for broken authorisation.
• Logs, backups and forgotten endpoints are part of the information lifecycle.
• API security requires inventory, testing and operational governance.
• Security controls must be tested against realistic business workflows.

7. Challenges, Ethics and Contemporary Developments

Cloud services, serverless functions, containers and service meshes increase scalability but create distributed trust boundaries. Organisations must know which provider can access data, where processing occurs, how logs and backups are retained, and how identity is federated. Zero-trust architecture reinforces continuous verification, least privilege and explicit policy rather than implicit trust based on network location.

Artificial intelligence introduces both opportunity and risk. AI-assisted coding may identify patterns or generate tests, but generated code can contain insecure assumptions, license concerns, hallucinated APIs or exposed secrets. AI systems may process confidential prompts, and AI-enabled applications face risks such as prompt injection, insecure tool use, data leakage and excessive agency. Human review, controlled data handling, model access restrictions and adversarial testing remain necessary.

Security testing must be authorised, proportionate and privacy-preserving. Penetration testing without permission can itself be unlawful or disruptive. Researchers need responsible disclosure channels, safe handling of discovered data and respect for affected individuals. Organisations should avoid collecting more telemetry than needed and should explain automated decisions when they materially affect people.

Best-Practice Checklist

• classify data and assign accountable owners;
• map copies across applications, APIs, logs, backups and suppliers;
• encrypt sensitive data in transit and at rest using managed keys;
• use authenticated encryption and safe password hashing;
• enforce server-side least-privilege authorisation on every sensitive operation;
• maintain an API inventory and retire obsolete interfaces;
• validate inputs, encode outputs and use parameterised queries;
• protect secrets and tokens from source code, logs and URLs;
• combine SAST, DAST, SCA, testing and expert review;
• apply rate limits, quotas and abuse monitoring;
• define retention, legal-hold and verified disposal procedures; and
• integrate security evidence, exceptions and incident learning into DevSecOps governance.

Chapter Summary

Data, application and API security form an integrated protection system. Information should be classified and controlled throughout creation, use, sharing, storage, retention and disposal. Encryption protects confidentiality and, with authenticated modes, integrity, but it depends on sound key management. Least privilege, separation of duties and server-side authorisation reduce misuse. DLP, privacy controls, retention schedules and secure disposal address risks beyond the application itself.

Web applications commonly fail through injection, broken access control, authentication weaknesses, misconfiguration, vulnerable components and inadequate logging. APIs add risks involving object ownership, function permissions, excessive data exposure, resource exhaustion, inventory and business logic. OWASP guidance provides an important awareness foundation, while threat modelling, secure coding, testing and operational monitoring provide the broader security discipline.

DevSecOps makes security continuous by integrating it into design, coding, build, deployment and operation. Effective practice is risk-based, measurable and governed, with explicit responsibility and ethical consideration. The most important principle is that security controls must be applied where data and business decisions actually occur, not assumed to be provided by a perimeter, gateway or security label alone.

Key Terms

API: A defined interface through which software systems exchange requests and responses.

Authentication: Verification of an identity or system origin.

Authorisation: Determination of what an authenticated subject may do.

Authenticated encryption: Encryption that provides confidentiality and integrity when correctly used.

Classification: Assignment of a sensitivity and handling category to information.

CSRF: An attack that induces a browser to perform an unwanted authenticated action.

DLP: Controls that detect or prevent inappropriate disclosure or transfer of data.

Encryption at rest: Protection of stored data using cryptographic transformation.

Encryption in transit: Protection of data while moving between systems.

Least privilege: Granting only the access necessary for an approved task.

OWASP: An open community and body of guidance focused on application security.

Rate limiting: Restricting request frequency or resource consumption.

Retention schedule: A rule specifying how long records are kept and when disposal may occur.

Secure disposal: Controlled destruction or erasure that prevents practical recovery.

SAST: Automated analysis of source or intermediate code for security weaknesses.

SCA: Analysis of third-party dependencies and their vulnerabilities.

Threat modelling: Structured identification of assets, trust boundaries, threats and mitigations.

TLS: A protocol family that protects communications and authenticates endpoints when correctly configured.

Token: Data representing a claim, session or permission used by an application.

XSS: Injection of attacker-controlled script into content executed by another user’s browser.

Review Questions

Short Answer Questions

1. Distinguish confidentiality, integrity and availability.
2. Why is encryption alone insufficient to protect an API resource?
3. What is the difference between authentication and authorisation?
4. State two reasons why application deletion may not remove all copies of data.
5. Name three security testing approaches used in a DevSecOps pipeline.

Long Answer Questions

1. Explain how an organisation should protect information across its lifecycle, from collection through secure disposal.
2. Discuss the relationship between least privilege, role-based access control and server-side authorisation.
3. Explain major web application risks identified by OWASP and provide appropriate controls.
4. Describe a comprehensive security architecture for a public-facing API serving sensitive data.
5. Evaluate the benefits and limitations of integrating security into DevSecOps.

Analytical / Application Questions

1. An authenticated customer can change an invoice identifier in an API request and view another customer’s invoice. Classify the vulnerability, identify the failed control and propose tests and remediation.
2. A company stores customer data in a database, daily snapshots, application logs and a third-party analytics platform. Design a classification, encryption, retention and disposal plan that addresses all copies.
3. A development team wants to block every software scanner finding before deployment. Analyse the likely operational consequences and design a risk-based exception and remediation policy.

Multiple Choice Questions with Answers

Question 1

Which control directly addresses a user changing an object identifier to access another user’s record?

A. Server-side object-level authorisation

B. Full-disk encryption

C. A longer password-expiration period

D. A public privacy notice

Correct Answer: A. Server-side object-level authorisation

Question 2

What is the primary purpose of encryption in transit?

A. To remove the need for authorisation

B. To protect data while it moves between systems

C. To guarantee application availability

D. To delete data after use

Correct Answer: B. To protect data while it moves between systems

Question 3

Which practice is most appropriate for storing user passwords?

A. Reversible encryption with one shared key

B. Plain text in a protected database table

C. Salted, slow password hashing such as Argon2id

D. Base64 encoding

Correct Answer: C. Salted, slow password hashing such as Argon2id

Question 4

Which OWASP-related risk occurs when untrusted input changes the meaning of an interpreter command?

A. Injection

B. Security misconfiguration

C. Insufficient backup retention

D. Physical theft

Correct Answer: A. Injection

Question 5

Why is an API inventory important?

A. It ensures every endpoint is publicly accessible

B. It identifies interfaces that must be governed, tested and retired

C. It replaces authentication

D. It prevents all denial-of-service attacks

Correct Answer: B. It identifies interfaces that must be governed, tested and retired

Question 6

A bearer token should be treated as sensitive primarily because:

A. anyone possessing it may be able to use its granted authority

B. it can never expire

C. it automatically encrypts all database records

D. it is valid only when printed on paper

Correct Answer: A. anyone possessing it may be able to use its granted authority

Question 7

Which control is most directly associated with preventing excessive API resource consumption?

A. Rate limits and quotas

B. Output encoding only

C. Data classification labels only

D. Longer database table names

Correct Answer: A. Rate limits and quotas

Question 8

What is the main purpose of a retention schedule?

A. To keep all information permanently

B. To define how long records are kept and when disposal may occur

C. To replace encryption keys automatically

D. To guarantee that backups contain no personal data

Correct Answer: B. To define how long records are kept and when disposal may occur

Question 9

Which statement about OAuth 2.0 is correct?

A. It is primarily an authorisation framework

B. It eliminates the need for TLS

C. It guarantees that every token is encrypted

D. It is a database backup standard

Correct Answer: A. It is primarily an authorisation framework

Question 10

Which combination best represents a mature DevSecOps approach?

A. Security testing only after a breach

B. Manual perimeter review without code analysis

C. Threat modelling, automated checks, expert review and runtime monitoring

D. Blocking every scanner alert regardless of risk

Correct Answer: C. Threat modelling, automated checks, expert review and runtime monitoring