8. Web, API, Mobile and Cloud-Native Application Security

Introduction and Context

Modern software rarely operates as an isolated program. A web application may depend on browser code, REST or GraphQL APIs, identity providers, mobile clients, databases, containers, orchestration platforms, serverless functions, and numerous third-party services. This distributed architecture increases capability and scalability, but it also expands the attack surface. A weakness in a browser interaction, API authorization rule, mobile storage mechanism, container image, Kubernetes policy, or cloud configuration can compromise an entire business process.

Application security therefore has to be understood as a system property rather than as a collection of isolated coding techniques. The security of a service depends on trust boundaries, identities, data flows, configuration, deployment practices, and operational controls. The same business function may be exposed through a browser, a mobile application, and an API; securing only one interface creates an illusion of protection.

This chapter examines security risks and defensive approaches across web, API, mobile, and cloud-native environments. It applies OWASP-style thinking to practical architecture and emphasizes authorization, secure state management, service identity, configuration governance, and shared responsibility in cloud systems.

Learning Objectives

After completing this chapter, students should be able to:

1. Explain major vulnerability classes affecting web applications, REST and GraphQL APIs, mobile applications, containers, Kubernetes, functions, and microservices.

2. Analyze browser trust boundaries, authentication and authorization flows, and common cross-origin risks.

3. Design stronger API gateways, service identities, input validation, rate controls, and object-level authorization.

4. Evaluate mobile client storage, network communication, secrets, and platform security assumptions.

5. Apply secure practices to container images, Kubernetes workloads, serverless functions, and microservice communication.

6. Interpret the cloud shared-responsibility model and identify organizational, technical, and governance obligations.

7. Develop a risk-based security strategy for distributed applications.

A Security Model for Distributed Applications

A useful starting point is the flow of an asset through a system. Assets may include credentials, personal information, payment data, business transactions, source code, tokens, and operational secrets. For each asset, the analyst should ask: where is it created, where is it transmitted, where is it stored, which identities may access it, and what happens if it is modified or disclosed?

Threat modeling methods such as STRIDE help structure this inquiry. Spoofing concerns identity impersonation; tampering concerns unauthorized modification; repudiation concerns the inability to prove an action; information disclosure concerns exposure of data; denial of service concerns loss of availability; and elevation of privilege concerns obtaining permissions beyond those granted. In cloud-native systems, these threats may cross several administrative and technical boundaries.

The principle of least privilege is especially important. A browser should not receive data it does not need, a service should not possess unrestricted database credentials, and a Kubernetes workload should not automatically obtain broad control over the cluster. Defense in depth combines preventive, detective, and corrective controls: validation and authorization prevent misuse, logging and monitoring reveal suspicious behavior, and revocation, isolation, and recovery limit impact.

Security decisions must also distinguish authentication from authorization. Authentication establishes who or what is making a request. Authorization determines whether that identity may perform the requested action on the specified resource under the relevant conditions. Many serious API breaches occur because authentication is implemented correctly while object-level authorization is incomplete.

Web Applications: The Browser as a Security Boundary

A browser is an untrusted execution environment from the perspective of the server. Client-side checks can improve usability but cannot enforce business authorization, because users can alter requests, execute scripts, or call endpoints directly. Sensitive decisions must therefore be repeated on the server.

Injection and unsafe interpretation

Injection occurs when untrusted data is interpreted as code or commands. SQL injection results when application data is concatenated into database queries. Command injection, template injection, LDAP injection, and expression-language injection follow the same general pattern. Parameterized queries, safe APIs, context-sensitive output encoding, and restrictive allowlists are preferable to attempting to remove a few dangerous characters.

Cross-site scripting (XSS) occurs when attacker-controlled content is executed as script in another user's browser. Reflected XSS is returned immediately in a response, stored XSS persists in an application, and DOM-based XSS arises through unsafe client-side processing. Output encoding must match the context: HTML, attribute, JavaScript, CSS, and URL contexts have different rules. A Content Security Policy can reduce the impact of XSS, but it is not a substitute for correct encoding and safe DOM APIs.

Cross-site request forgery (CSRF) exploits a browser's automatic inclusion of credentials. If a victim is logged in and visits a malicious site, that site may cause the browser to submit an unwanted state-changing request. Effective defenses include unpredictable CSRF tokens, SameSite cookie settings, origin or referer validation where appropriate, and an API design that does not rely on ambient credentials for unsafe operations. A bearer token held in a carefully designed authorization header is not automatically immune to all browser attacks, particularly if it can be stolen through XSS.

Sessions, cookies, and browser policy

Session identifiers must be unpredictable, rotated after authentication or privilege changes, invalidated on logout where feasible, and protected with Secure, HttpOnly, and suitable SameSite attributes. Cookie scope should be as narrow as practical. Long-lived sessions require risk-based reauthentication, revocation, and monitoring.

The same-origin policy prevents scripts in one origin from freely reading data belonging to another. Cross-Origin Resource Sharing (CORS) selectively relaxes this policy. A dangerous configuration reflects arbitrary origins while permitting credentials. CORS is an access-control mechanism for browser reads, not a replacement for server-side authorization. Preflight requests, allowed methods, headers, and credential behavior must be explicitly configured.

Clickjacking can cause users to interact with an application while viewing an attacker-controlled frame. Frame-ancestors in Content Security Policy and appropriate frame options help reduce this risk. Security headers should be treated as part of an application baseline, not as cosmetic configuration.

Business logic and access control

Not all vulnerabilities are technical parser failures. A transfer endpoint may permit a negative amount, a coupon may be reused, or a user may alter an account identifier in a legitimate request. These are business-logic and authorization failures. Controls must validate workflow state, ownership, transaction limits, and segregation of duties. Security testing should include misuse cases designed with domain experts.

REST and GraphQL API Security

APIs expose structured capabilities and are often consumed by browsers, mobile applications, partners, and internal services. Their predictable interfaces make automation easy for both legitimate users and attackers.

REST security concerns

Every endpoint should define the identity, resource, action, and context required for access. Object-level authorization must be enforced for each retrieved or modified object. A request such as `/orders/4812` is not safe merely because the caller is authenticated; the server must establish that the caller may access order 4812.

Function-level authorization is equally important. Administrative operations should not become available because a user changes an HTTP method or discovers an undocumented route. Mass assignment is another risk: automatically binding JSON fields to internal objects may allow clients to set fields such as `role`, `approved`, or `accountId`. Explicit input models and server-controlled fields reduce this risk.

APIs should validate syntax, type, size, range, and semantic relationships. They should reject unexpected fields when appropriate, limit pagination and query complexity, and avoid returning excessive data. Rate limiting should be tied to the resource and risk, rather than implemented only as a broad request-per-second threshold. Authentication failures, authorization denials, unusual enumeration, and high-volume data access should be observable without logging secrets or sensitive payloads.

Tokens must be validated for signature, issuer, audience, expiry, and relevant claims. A token should not be accepted simply because it is structurally well formed. Key rotation, revocation strategy, clock tolerance, and algorithm restrictions require explicit design.

GraphQL-specific issues

GraphQL allows clients to request fields through a schema and can reduce over-fetching, but it creates distinctive risks. Deeply nested queries can consume excessive resources; aliases and fragments can complicate monitoring; introspection may reveal sensitive design information; and field-level authorization can be overlooked when only the endpoint is protected.

Defenses include query depth and cost limits, pagination bounds, timeouts, persisted or allowlisted queries for sensitive clients, resolver-level authorization, and resource-aware rate controls. Disabling introspection may be useful in some production contexts, but it does not repair authorization. Errors should be informative to legitimate developers without disclosing stack traces, database details, or internal topology.

API gateways and service boundaries

An API gateway can centralize TLS termination, authentication integration, request normalization, rate controls, schema validation, and logging. It cannot replace authorization in downstream services because business ownership and resource context often exist only there. Gateway policies should be version-controlled, tested, and reviewed like application code.

Microservices should use explicit service identities rather than trusting network location. Mutual TLS, signed service tokens, workload identities, and short-lived credentials can establish service-to-service identity. Authorization policies should express both the calling service and the intended operation. Network segmentation reduces reachability but should not be treated as proof of trust.

Mobile Application Security

Mobile applications operate on devices controlled by users and may be reverse engineered, instrumented, rooted, or connected through hostile networks. A mobile client is therefore not a trusted place to enforce authorization or store permanent secrets.

Sensitive data should be minimized and stored using platform-provided protected storage, such as a hardware-backed keystore or secure keychain where available. Plaintext tokens in shared preferences, logs, files, screenshots, or backups are common weaknesses. Applications should classify data before storing it and define retention and deletion behavior.

Transport security requires modern TLS, certificate validation, and careful handling of redirects and proxy configurations. Certificate pinning can reduce certain interception risks, but it increases operational complexity during certificate rotation and can be bypassed on compromised devices. It should be adopted only with a recovery and update strategy.

The server must assume that mobile requests can be reproduced outside the official application. Device attestation may provide risk signals, but it is not a substitute for server-side authorization. Deep links and universal links require validation to prevent malicious redirection or unauthorized action. Web views should restrict navigation, avoid exposing native bridges unnecessarily, and separate untrusted content from privileged application functionality.

Mobile applications also raise privacy questions. Permissions should be proportionate, consent should be meaningful, and telemetry should avoid collecting unnecessary identifiers. Debug builds, embedded API keys, verbose logs, and exported platform components require release-time review.

Containers, Kubernetes, and Cloud-Native Workloads

Containers package an application and its dependencies, but they are not complete virtual machines. The kernel is shared, and an escaped or overly privileged process may affect the host or other workloads. Security begins with a minimal, trusted base image, pinned dependencies, vulnerability scanning, signed artifacts, and a controlled build pipeline. Images should run as non-root users, drop unnecessary Linux capabilities, use read-only filesystems where possible, and avoid embedding secrets.

A software bill of materials (SBOM) improves visibility into components and supports vulnerability response. Scanning alone is insufficient: teams must prioritize exploitable vulnerabilities, update dependencies, and understand whether vulnerable code is reachable.

Kubernetes introduces an additional control plane and a declarative configuration layer. Role-Based Access Control should grant only the verbs and resources needed by each human or workload. Service accounts should not receive broad permissions by default, and tokens should be short-lived or projected where supported. Network policies can restrict pod-to-pod communication; admission controls can enforce image provenance, security contexts, and approved registries.

Namespaces provide organization and some isolation, but they are not an automatic security boundary for high-risk tenants. Secrets should be protected in storage and access, with external secret managers often preferable to unencrypted configuration objects. The API server, etcd, kubelet interfaces, ingress controllers, and cloud metadata services require particular attention.

Configuration drift is a major operational risk. Infrastructure and policy should be defined as code, reviewed, tested, and reconciled continuously. Runtime detection can identify unexpected processes, network connections, privilege changes, and image behavior. Observability should include application logs, audit events, metrics, and traces while respecting data minimization.

Functions and event-driven systems

Serverless functions reduce infrastructure management but introduce risks involving event parsing, dependency reuse, excessive permissions, insecure triggers, and uncontrolled invocation costs. Each function should have a narrowly scoped execution role. Events from queues, storage services, webhooks, and message buses must be authenticated and validated because event sources may be spoofed or replayed.

Cold-start behavior, temporary directories, global variables, and connection reuse can create data leakage or unexpected state if developers assume every invocation is a pristine process. Functions require timeouts, concurrency controls, dead-letter handling, idempotency, and monitoring. Dependency packages and layers should be scanned and updated.

Cloud Shared Responsibility and Governance

Cloud providers generally secure the physical facilities, foundational hardware, and selected managed-service layers. Customers remain responsible for identities, data, configurations, workloads, and access decisions; the exact division varies by service model. Using a managed database does not eliminate responsibility for database users, network exposure, encryption choices, backups, or retention.

A practical governance model maps every asset and control to an owner. Identity and access management should use federation, multifactor authentication, separation of duties, privileged-access workflows, and periodic access review. Cloud logs should be centralized, protected from alteration, monitored, and connected to incident response. Encryption key ownership, rotation, recovery, and destruction require explicit policy.

Misconfiguration is often more probable than a sophisticated exploit. Public storage, unrestricted security groups, exposed management interfaces, permissive identity policies, disabled audit logs, and hard-coded credentials should be detected through policy-as-code and continuous posture management. Compliance frameworks can guide control design, but compliance evidence is not equivalent to security assurance.

An Applied Case: Securing a Digital Commerce Platform

Background

The following is an illustrative case. A mid-sized retailer operates a web storefront, an Android and iOS mobile application, a GraphQL API for product and order data, Kubernetes-based microservices, and cloud-hosted databases. The company recently introduced a loyalty service and outsourced payment processing.

Situation and problem

A security review found that customers could alter an order identifier in a mobile request and view another customer's order summary. The GraphQL endpoint accepted deeply nested queries that caused high CPU use. A Kubernetes service account had permission to list secrets across a namespace, and a cloud storage bucket containing application logs was publicly readable. The organization had passed a checklist-based compliance review but lacked a unified ownership model.

Analysis

The order disclosure was an object-level authorization failure, not an authentication failure. The GraphQL issue represented uncontrolled resource consumption. The service-account permission violated least privilege and increased the impact of a compromised pod. The public bucket created an information-disclosure risk, potentially including personal data. These findings were connected: weak governance allowed different teams to make locally convenient but globally unsafe decisions.

Approach and solution

The retailer first classified data and mapped flows from clients through gateways, services, queues, and storage. The order service began deriving the customer identity from the validated server-side session rather than trusting a client-supplied owner field. Authorization checks were placed in the service layer and covered read, update, cancellation, and refund operations.

The GraphQL gateway introduced persisted queries for mobile clients, depth and cost limits, bounded pagination, timeouts, and resolver-level authorization. Kubernetes roles were rewritten around specific resources and verbs; service accounts were separated by workload, and admission policies rejected privileged containers and unapproved images. The storage bucket became private, logs were redacted, and access was routed through controlled analytics services.

The organization then implemented federated identity, multifactor authentication, centralized audit logging, dependency and image scanning, infrastructure-as-code review, and incident exercises. Security tests included horizontal and vertical authorization abuse, replayed mobile requests, malicious event payloads, and cloud configuration checks.

Outcome

The immediate vulnerabilities were removed, but the more important outcome was a repeatable control system. Ownership was assigned for each data store and service, security requirements were included in design reviews, and monitoring focused on unusual object enumeration, privilege use, query cost, and public exposure. The company accepted that no single gateway, scanner, or mobile control could secure the platform alone.

Learning points

The case demonstrates four principles. First, authorization must be evaluated at the resource and action level. Second, cloud-native security is inseparable from identity and configuration management. Third, performance abuse is an application-security concern when flexible APIs permit expensive requests. Finally, governance converts isolated technical fixes into durable organizational capability.

Challenges, Limitations, and Common Mistakes

A frequent mistake is treating security tools as proof of security. Static analysis may miss business-logic flaws, dynamic testing may not understand authorization context, and vulnerability scanners may produce excessive noise. Tools require threat-informed interpretation and remediation ownership.

Another mistake is centralizing all security in an API gateway. Gateways are valuable for common controls, but services must still verify identity, resource ownership, and business rules. Similarly, network segmentation does not compensate for compromised credentials or vulnerable services.

Teams also overtrust client-side protections, certificate pinning, hidden mobile endpoints, private container registries, or Kubernetes namespaces. These controls can raise attack cost but do not remove the need for server-side enforcement. Excessive logging creates privacy and breach risk, while insufficient logging prevents investigation. Security controls must therefore be proportionate, observable, testable, and maintainable.

Ethical, Regulatory, and Professional Considerations

Application security involves personal data, employee information, financial records, and potentially sensitive behavioral profiles. Collection should be limited to a legitimate purpose, access should be justified, and retention should be controlled. Security testing must be authorized, scoped, and conducted without exposing real customer data unnecessarily.

Developers and security professionals have a duty to disclose vulnerabilities responsibly, protect credentials discovered during testing, and document residual risk honestly. Managers should not pressure teams to conceal incidents or classify known weaknesses as acceptable without evidence. Regulatory obligations vary by jurisdiction and sector, but privacy, breach notification, access control, auditability, and resilience are recurring themes.

Current Developments and Best Practices

Software supply-chain security is becoming more important as applications depend on open-source packages, base images, build actions, and external services. Signed artifacts, provenance attestations, reproducible or controlled builds, dependency policies, and rapid revocation improve confidence in what reaches production.

Zero-trust approaches increasingly influence cloud-native design: every request is evaluated using identity, context, policy, and resource sensitivity rather than assumed trust based on network location. Policy-as-code and automated security gates can make secure defaults repeatable, although poorly designed policies may block legitimate work or encourage bypasses.

AI-assisted coding and automated configuration generation can improve productivity but may introduce vulnerable code, insecure dependencies, excessive permissions, or fabricated assumptions. Generated artifacts require the same review, testing, threat modeling, and provenance controls as human-authored artifacts.

A mature program combines the following practices:

• model threats and data flows before implementation;
• enforce authorization in every service that owns a resource;
• use short-lived, narrowly scoped human and service identities;
• validate inputs and constrain resource consumption;
• protect secrets through managed storage and rotation;
• secure builds, dependencies, images, and deployment policies;
• continuously monitor configuration, access, and runtime behavior;
• test recovery, revocation, and incident response;
• measure remediation quality rather than merely counting findings.

Chapter Summary

Web, API, mobile, and cloud-native security must be designed across the complete application system. Browser controls such as cookies, CORS, CSP, and CSRF defenses reduce client-side risk, but server-side validation and authorization remain decisive. REST and GraphQL services require object-level and function-level authorization, bounded inputs, token validation, query-cost controls, and appropriate rate limiting. Mobile clients are untrusted and should minimize stored data, protect credentials with platform facilities, and rely on servers for security decisions.

Containers, Kubernetes, functions, and microservices extend the attack surface through images, service accounts, roles, event triggers, secrets, and configuration. Least privilege, workload identity, admission controls, network policies, signed artifacts, and observability provide layered defenses. The cloud shared-responsibility model assigns obligations to both provider and customer; managed infrastructure does not remove responsibility for identity, data, configuration, or monitoring. Effective security combines technical controls with governance, privacy, professional ethics, continuous testing, and accountable ownership.

Key Terms

Authentication: Verification of the identity of a user, device, or service.

Authorization: Determination of whether an authenticated identity may perform an action on a resource.

CSRF: An attack that causes a victim’s browser to submit an unwanted authenticated request.

CORS: A browser mechanism that permits controlled cross-origin requests.

CSP: A browser policy that restricts permitted content sources and can reduce XSS impact.

XSS: Execution of attacker-controlled script in a victim’s browser context.

Object-level authorization: Permission checking applied to a specific resource instance.

Mass assignment: Unsafe automatic binding of client fields to internal application objects.

GraphQL resolver: A function that obtains or processes data for a GraphQL field.

API gateway: An intermediary that applies common controls to API traffic.

Service identity: A verifiable identity assigned to an application workload or service.

Container image: A packaged filesystem and metadata used to instantiate a container.

SBOM: An inventory of components and dependencies contained in a software artifact.

Kubernetes RBAC: Role-based control governing access to Kubernetes resources and operations.

Admission control: Policy enforcement applied before a workload or resource is accepted by a platform.

Serverless function: A cloud-executed unit of code invoked by requests or events without customer-managed servers.

Workload identity: A mechanism through which software obtains an identity without embedded long-lived credentials.

Shared responsibility: The division of security obligations between a cloud provider and its customer.

Policy-as-code: Encoding security or governance rules in machine-evaluable, version-controlled form.

Review Questions

Short Answer Questions

1. Why is object-level authorization necessary even when an API authenticates users correctly?

2. Distinguish reflected XSS from stored XSS.

3. State two security risks specific to GraphQL APIs.

4. Why should containers generally avoid running as root?

5. What does the cloud shared-responsibility model require from a customer?

Long Answer Questions

1. Explain how cookies, SameSite attributes, CSRF tokens, CORS, and CSP contribute to browser security.

2. Discuss a secure design for REST API authentication, authorization, validation, rate limiting, and logging.

3. Analyze the security controls required for a Kubernetes-based microservices platform.

4. Explain why a mobile application cannot be treated as a trusted enforcement point.

5. Describe how governance and technical controls should be combined to secure cloud-native applications.

Analytical / Application Questions

1. A user can modify an order ID in a request and retrieve another customer’s order. Identify the vulnerability, explain why authentication does not prevent it, and propose a service-layer remedy.

2. A GraphQL API experiences resource exhaustion from deeply nested queries. Design a control strategy that balances legitimate flexibility with availability protection.

3. A cloud workload has a public log bucket, a broadly permissioned service account, and an image containing a vulnerable dependency. Prioritize the response and justify your sequence using risk and shared-responsibility principles.

22. Multiple Choice Questions with Answers

Question 1

A REST API authenticates a customer but allows the customer to request any order by changing the order identifier. Which vulnerability is most directly present?

A. Object-level authorization failure

B. Cross-site request forgery

C. Container escape

D. Certificate pinning failure

Correct Answer: A. Object-level authorization failure

Question 2

Which control most directly limits resource exhaustion caused by deeply nested GraphQL queries?

A. Disabling all TLS encryption

B. Query depth and cost limits

C. Increasing token lifetime

D. Allowing unrestricted introspection

Correct Answer: B. Query depth and cost limits

Question 3

Why can client-side authorization checks not be relied upon for a mobile application?

A. Mobile applications cannot use encryption

B. Users can reverse engineer or reproduce client requests

C. Mobile devices never support secure storage

D. Servers cannot authenticate mobile users

Correct Answer: B. Users can reverse engineer or reproduce client requests

Question 4

Which combination best reduces the risk of CSRF in a cookie-based web session?

A. CSRF tokens and appropriate SameSite cookies

B. Longer session expiration and unrestricted CORS

C. Client-side validation and hidden URLs

D. Disabling server-side authorization

Correct Answer: A. CSRF tokens and appropriate SameSite cookies

Question 5

What is the principal security purpose of Kubernetes RBAC?

A. Compressing container images

B. Controlling access to Kubernetes resources and operations

C. Encrypting all application responses

D. Preventing SQL injection in services

Correct Answer: B. Controlling access to Kubernetes resources and operations

Question 6

Which practice best protects a cloud-native service from excessive privilege?

A. Using one administrator account for all workloads

B. Granting each workload a narrowly scoped service identity

C. Trusting all traffic inside the cluster

D. Embedding permanent credentials in the image

Correct Answer: B. Granting each workload a narrowly scoped service identity

Question 7

A browser application reflects arbitrary origins while allowing credentialed requests. What is the main concern?

A. Unsafe CORS configuration

B. Insufficient container scanning

C. Missing SBOM generation

D. Improper function timeout

Correct Answer: A. Unsafe CORS configuration

Question 8

Which statement best describes the cloud shared-responsibility model?

A. The provider is responsible for every customer configuration

B. The customer is responsible for physical data-center security

C. Provider and customer responsibilities vary by service, with customers retaining duties for identities, data, and configuration

D. Managed services eliminate the need for customer security controls

Correct Answer: C. Provider and customer responsibilities vary by service, with customers retaining duties for identities, data, and configuration

Question 9

Which control is most appropriate for preventing mass assignment of privileged fields such as role or approval status?

A. Explicit input models that exclude server-controlled fields

B. Increasing API response size

C. Disabling audit logging

D. Allowing arbitrary JSON fields

Correct Answer: A. Explicit input models that exclude server-controlled fields

Question 10

Why are signed artifacts, dependency controls, and image provenance important in cloud-native development?

A. They guarantee that no application vulnerability exists

B. They help establish what software entered the build and deployment chain

C. They replace authorization checks in services

D. They prevent all denial-of-service attacks

Correct Answer: B. They help establish what software entered the build and deployment chain