Secure Applications, Cloud, Mobile and IoT

Introduction

Cybersecurity is no longer confined to a perimeter around desktop computers and corporate data centres. Modern organisations deliver services through web applications, application programming interfaces (APIs), cloud platforms, mobile applications, operational technology (OT), and Internet of Things (IoT) devices. These environments increase capability and scalability, but they also create interdependent attack surfaces. A weakness in a mobile application may expose an API; an incorrectly configured cloud storage service may disclose sensitive records; and an insecure IoT device may provide a pathway into an operational network.

This chapter examines security across these environments. It uses the OWASP guidance as a practical foundation for application and API security, introduces secure development lifecycle practices, and applies the shared-responsibility model to cloud security. It also addresses mobile, OT and IoT risks, with particular attention to identity, configuration, data protection, monitoring, resilience and governance.

Learning Objectives

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

1. Recognise common web application and API weaknesses using OWASP guidance.
2. Explain how security activities are integrated into a secure development lifecycle.
3. Apply identity, access-control, configuration and data-protection principles in cloud environments.
4. Identify distinctive security risks in mobile, OT and IoT systems.
5. Recommend proportionate controls for applications, cloud services, mobile devices, OT and IoT.
6. Evaluate security decisions in relation to safety, privacy, resilience, ethics and regulatory obligations.

1. The Modern Application and Infrastructure Landscape

A contemporary service commonly consists of a user interface, mobile clients, APIs, databases, cloud infrastructure, third-party services and connected devices. Security therefore depends on relationships between components rather than on a single product.

Three characteristics are especially important:

• Distributed trust: A service may rely on identity providers, cloud vendors, software libraries and managed databases.
• Rapid change: Continuous integration and deployment can release code and infrastructure changes many times per day.
• Convergence: IT networks increasingly interact with OT, sensors, vehicles, medical devices and building-management systems.

The traditional security objective of confidentiality, integrity and availability (CIA) remains central. However, OT and IoT also require safety, reliability, maintainability, privacy and physical security. A control that improves confidentiality but interrupts a safety-critical process may be inappropriate.

Important terminology

An application is software that performs services for users or other systems. An API is a defined interface through which software exchanges requests and responses. A cloud service provides computing, storage, networking or software capabilities through a provider-managed environment. Mobile security concerns applications, operating systems, devices, wireless communications and mobile management. OT monitors or controls physical processes. IoT refers broadly to networked physical objects containing sensors, software and connectivity.

2. OWASP-Based Application and API Security

The Open Worldwide Application Security Project (OWASP) publishes widely used guidance, including the OWASP Top 10 for web applications and the OWASP API Security Top 10. These lists are awareness and prioritisation tools, not a complete security standard. They should be combined with threat modelling, secure coding standards, testing, operational monitoring and risk assessment.

2.1 Broken access control

Broken access control occurs when a user can perform an action or access an object beyond the permissions intended by the system. Examples include viewing another customer’s invoice by changing an identifier in a URL, invoking an administrator endpoint as a normal user, or modifying a record through an undocumented API field.

A robust design follows least privilege, deny by default, and server-side enforcement. Authorisation must be checked for every sensitive operation, not merely when a menu item is displayed. Object-level authorisation is particularly important in APIs: possession of a valid token does not automatically authorise access to every object.

2.2 Cryptographic failures

Sensitive data can be exposed through weak algorithms, poor key management, incorrect certificate validation, excessive data collection or transmission without adequate protection. Transport Layer Security (TLS) should protect data in transit, while encryption or strong access controls should protect data at rest where appropriate.

Encryption does not remove the need for access control. If an application server can decrypt every record using one unrestricted key, compromise of that server may expose the entire database. Good practice includes key separation, restricted key access, rotation, secure backup and auditable key use. Passwords should not be encrypted reversibly; they should be stored using a slow, salted password-hashing function such as Argon2id, scrypt or an appropriately configured bcrypt implementation.

2.3 Injection

Injection occurs when untrusted input is interpreted as commands or code. SQL injection, command injection, LDAP injection and cross-site scripting (XSS) are common examples. The principal defence is to separate data from instructions using parameterised queries, safe APIs, context-appropriate output encoding and strict input validation.

Input validation is useful but cannot replace parameterisation. A blacklist such as “reject the word SELECT” is fragile because attackers can use alternate syntax or encoding. Validation should define the expected type, length, range and format, while the underlying interface must still safely handle untrusted data.

2.4 Insecure design

Insecure design is a weakness in architecture or requirements rather than merely a coding error. Examples include allowing unlimited password-reset attempts, failing to define transaction limits, or designing a sensitive workflow without fraud controls. Threat modelling should occur before implementation and should consider assets, trust boundaries, abuse cases, likely attackers and consequences.

2.5 Security misconfiguration

Misconfiguration includes default passwords, unnecessary services, verbose error messages, permissive cloud storage, debug mode in production, missing security headers and inconsistent settings between environments. Secure configuration should be baselined, version-controlled, reviewed and tested. Configuration drift should be detected continuously.

2.6 Vulnerable and outdated components

Applications depend on operating systems, libraries, containers, frameworks and third-party services. A software bill of materials (SBOM) helps identify components and their versions. Organisations should maintain an inventory, monitor advisories, assess exploitability and patch according to risk. Updating without testing can cause outages, so release management and rollback planning are essential.

2.7 Identification and authentication failures

Authentication establishes identity; authorisation determines permitted action. Weaknesses include credential stuffing, predictable recovery questions, poor session management, missing multi-factor authentication (MFA), long-lived tokens and failure to invalidate sessions after a security event.

Good practice includes phishing-resistant MFA for privileged access where feasible, secure password recovery, short-lived access tokens, protected refresh tokens, session rotation after authentication, and rate limiting. Tokens should contain only necessary claims and should be validated for issuer, audience, signature, expiry and intended use.

2.8 Software and data integrity failures

An application may be compromised through an untrusted update, dependency, build pipeline or deserialisation process. Source-code review, protected build systems, signed artefacts, dependency pinning, provenance records and separation of duties reduce supply-chain risk. Deserialisation of untrusted data should be avoided or strictly controlled.

2.9 Security logging and monitoring failures

Logs support detection, investigation and accountability. Useful events include authentication failures, privilege changes, sensitive-data access, administrative actions, configuration changes and unusual API activity. Logs should be time-synchronised, protected from tampering and designed to avoid unnecessary personal or secret data. Logging alone is not monitoring: alerts require thresholds, ownership, triage and response procedures.

2.10 Server-side request forgery and API-specific weaknesses

Server-side request forgery (SSRF) occurs when an application fetches a resource based on attacker-controlled input and can be induced to access internal services. Defences include allow-listed destinations, network egress controls, URL parsing that resists alternate representations, metadata-service protections and separation of sensitive management networks.

API security additionally requires controls for excessive data exposure, unrestricted resource consumption, unsafe consumption of third-party APIs, improper inventory management and unrestricted access to sensitive business flows. APIs should have documented versions, an explicit schema, bounded request sizes, rate limits, pagination limits and business-level abuse detection.

3. Secure Development Lifecycle

A secure development lifecycle (SDL) integrates security into planning, design, implementation, verification, release and operation. Security is not a final penetration test; late testing may discover defects when they are expensive to correct.

Static application security testing (SAST) examines source or intermediate code. Dynamic application security testing (DAST) tests a running application. Software composition analysis (SCA) identifies vulnerable dependencies. None is sufficient alone: automated tools generate false positives and may miss business-logic flaws. Human review and abuse-case testing remain necessary.

A practical SDL uses risk-based gates. A critical remotely exploitable flaw should normally block release, whereas a low-risk informational issue may be documented and scheduled. Teams should measure meaningful outcomes such as time to remediate critical vulnerabilities, percentage of high-risk services with threat models, and recurrence of defects—not merely the number of scans completed.

4. Cloud Security and Shared Responsibility

Cloud security is governed by a shared-responsibility model. The provider usually secures the underlying facilities, hardware and core service infrastructure. The customer remains responsible for elements such as identities, data, workloads, network rules and configuration. The exact division depends on whether the service is infrastructure as a service (IaaS), platform as a service (PaaS) or software as a service (SaaS).

The model does not mean that responsibility is divided equally or permanently. Contracts, service features and deployment choices determine the actual obligations. A cloud provider may offer encryption, logging or MFA capabilities, but the customer must enable and configure them correctly.

Cloud control foundations

1. Identity first: Use central identity management, MFA, role-based access control, least privilege, privileged-access workflows and periodic access reviews.
2. Secure configuration: Use hardened templates, infrastructure as code, policy-as-code and automated drift detection. Prohibit public storage and unrestricted management interfaces unless explicitly justified.
3. Network segmentation: Separate production, development and management planes. Restrict east-west traffic and outbound connections as well as inbound traffic.
4. Data protection: Classify data, minimise collection, encrypt appropriate data, protect keys separately, control backups and define retention and deletion rules.
5. Visibility and response: Centralise audit logs, protect them from alteration, monitor identity and configuration events, and test incident-response procedures.
6. Resilience: Use tested backups, recovery objectives, availability-zone planning and dependency analysis. Replication is not automatically backup if deletion or corruption is replicated.

A frequent cloud failure is not a sophisticated exploit but an exposed resource, excessive permissions, leaked secret or unmonitored administrative account. Cloud security posture management tools can assist, but ownership and remediation workflows remain organisational responsibilities.

5. Mobile Application Security

Mobile applications operate in an environment controlled partly by the user, the mobile operating system and app marketplaces. An application must assume that its client code can be inspected and that local storage may eventually be accessed on a compromised device.

Sensitive data should be minimised and stored using platform-provided protected storage, such as a hardware-backed keystore where available. Hard-coded API keys, passwords and long-lived secrets in an application package are not secure because reverse engineering can reveal them. A mobile app should treat its client as an untrusted presentation layer and enforce authorisation at the server.

Important controls include:

• secure transport and proper certificate validation;
• short-lived tokens and secure refresh-token handling;
• platform permissions limited to the application’s genuine needs;
• protection against insecure deep links and exported components;
• prevention of sensitive data in screenshots, logs, backups and clipboard contents;
• secure update processes and signed packages;
• mobile device management (MDM) for organisational devices;
• jailbreak or root detection as a risk signal, not as a complete defence.

Mobile threats also include malicious or counterfeit applications, insecure Wi-Fi, notification leakage, lost devices, supply-chain compromise and privacy-invasive software development kits (SDKs). Privacy-by-design requires clear notice, meaningful consent where applicable, purpose limitation and deletion mechanisms.

6. Operational Technology Security

OT systems include industrial control systems, supervisory control and data acquisition (SCADA), building controls, manufacturing systems and critical infrastructure. Unlike many IT systems, OT priorities may place safety and continuous availability ahead of confidentiality. Equipment may have long lifecycles, proprietary protocols and limited patching capability.

A safe OT security programme begins with asset inventory and network visibility. Systems should be segmented into zones and conduits, with carefully controlled connections between enterprise IT, industrial demilitarised zones and control networks. Remote access should be limited, strongly authenticated, approved for a defined period and recorded. Vendor access requires governance rather than permanent shared accounts.

Changes must be tested in representative environments where possible. Active scanning or automated blocking can disrupt fragile equipment; passive monitoring and carefully scheduled maintenance may be safer. Incident response must include engineering and safety personnel, and recovery plans must address manual operation and physical consequences.

7. Internet of Things Security

IoT devices range from consumer cameras to medical sensors and industrial controllers. Their risks arise from scale, physical exposure, limited computing resources, heterogeneous suppliers and long operational lifetimes.

A secure IoT architecture should provide unique device identities, secure onboarding, mutual authentication where appropriate, encrypted communications, signed firmware, secure boot, protected credentials, minimal services, resilient update mechanisms and an end-of-life process. Devices should not share one default password. Network segmentation limits the consequences of compromise, while an inventory allows unsupported or vulnerable devices to be identified.

Manufacturers and operators should define vulnerability disclosure, update support periods, logging capabilities and data ownership. Procurement should evaluate security properties before purchase rather than treating security as an optional later enhancement. Where a device cannot be patched, compensating controls may include isolation, restricted egress, protocol gateways and replacement planning.

8. Applied Case: Cloud-Connected Healthcare Service

This is an illustrative case, not a report of a specific organisation.

Background

A regional healthcare provider introduces a mobile application allowing patients to view appointments, receive messages and upload documents. The service uses a cloud-hosted API, object storage and a third-party identity provider. Some diagnostic devices upload measurements through an IoT gateway.

Problem

A security review finds that a patient can alter an appointment identifier and view another patient’s document. The object-storage bucket is private, but a development account has permission to make it public. The API accepts unlimited document uploads, and device gateways use a shared credential. Logs record successful access but not failed authorisation attempts.

Analysis

The appointment weakness is broken object-level authorisation. The development permission creates a configuration and privilege-escalation risk. Unlimited uploads create resource-exhaustion and malware risks. Shared device credentials prevent accountability and allow compromise of one device to affect all gateways. Incomplete logs reduce detection and investigation capability. Healthcare data also creates substantial privacy and regulatory obligations.

Approach and solution

The provider first classifies clinical documents as highly sensitive and defines security acceptance criteria. The API now derives the patient identity from a validated token and checks ownership on every object request. Storage access is mediated by the application; time-limited download URLs are issued only after authorisation. Administrative roles are redesigned using least privilege, and public-storage policies are blocked automatically.

Uploads are limited by size, type, rate and account quota. Files are malware-scanned and stored outside executable paths. Each gateway receives a unique certificate and device identity, while the IoT network is isolated from clinical systems. MFA is required for administrators. Logs capture authentication, authorisation failures, document access, policy changes and device events, and are sent to a protected monitoring platform.

Outcome

The revised design reduces unauthorised disclosure, limits the effect of a compromised device and improves detection. It does not eliminate risk: stolen patient credentials, provider outages, vulnerable devices and human error remain possible. The organisation therefore adds recovery testing, supplier reviews, privacy impact assessment and periodic penetration testing.

Learning points

The case demonstrates that security is systemic. Correct encryption would not have fixed the authorisation flaw; a private bucket would not have corrected excessive administrative permissions; and device authentication must be combined with segmentation and monitoring. Controls should be selected according to both technical risk and the consequences of failure.

9. Governance, Ethics and Regulation

Security controls affect people, organisations and society. Excessive monitoring may intrude on privacy; collecting detailed device telemetry may create surveillance risks; and automated fraud detection may disadvantage particular groups. Security teams should apply necessity, proportionality, transparency, purpose limitation and data minimisation.

Organisations must identify applicable obligations, which may include data-protection law, breach-notification rules, sector-specific healthcare or financial requirements, contractual duties and product-safety expectations. Compliance is not equivalent to security. A checklist may demonstrate a baseline while missing a realistic attack path.

Boards and managers should assign clear ownership, fund remediation, approve risk acceptance and require evidence of resilience. Suppliers should be assessed for security practices, incident notification, data location, subcontracting, support duration and secure deletion. AI-assisted coding and cloud automation can increase productivity, but generated code and automated changes require review, testing, provenance and protection against secret leakage. AI systems themselves may introduce prompt injection, insecure generated code, data leakage and opaque decisions.

10. Contemporary Developments and Best Practice

Current practice is moving toward zero-trust architectures, identity-centric controls, software supply-chain security, confidential computing, passkeys, memory-safe languages, SBOMs, continuous control monitoring and secure-by-design regulation. These developments are valuable, but none is a substitute for basic asset inventory, least privilege, patching, secure configuration, tested backups and incident response.

A practical security improvement programme should:

1. maintain an accurate inventory of applications, APIs, cloud resources, mobile clients, OT assets and IoT devices;
2. classify data and identify safety-critical processes;
3. define owners and security requirements before deployment;
4. implement strong identity, least privilege and MFA;
5. use secure defaults and automated configuration policy;
6. integrate threat modelling and security testing into delivery;
7. protect secrets, keys, dependencies and build pipelines;
8. segment networks and constrain outbound access;
9. monitor meaningful security events and rehearse response;
10. test restoration, replacement and retirement procedures.

No architecture is permanently secure. Security is a continuing risk-management activity involving technology, people, process, suppliers and governance.

Chapter Summary

Applications and APIs must defend against access-control failures, injection, cryptographic failures, insecure design, misconfiguration, vulnerable components, authentication weaknesses, integrity failures, inadequate logging and SSRF. OWASP guidance provides a useful awareness structure, but effective security also requires threat modelling, secure design, testing and operational monitoring.

A secure development lifecycle embeds security from requirements through retirement. Cloud security follows a shared-responsibility model in which customers remain accountable for identities, data, workloads and configuration even when infrastructure is operated by a provider. Mobile applications must treat the client as potentially observable and enforce sensitive decisions server-side. OT security must balance confidentiality with safety, availability and physical consequences. IoT security depends on unique identity, secure updates, segmentation, lifecycle management and supplier accountability.

Across all environments, the strongest foundations are asset visibility, least privilege, secure configuration, data minimisation, protected credentials, monitoring, tested recovery and clear governance. Ethical and regulatory considerations must shape controls, particularly where systems process personal data or influence physical safety.

Key Terms

OWASP: A community project publishing application-security guidance and tools.

API: An interface that enables software systems to communicate.

Broken access control: Unauthorised ability to view, change or execute resources or functions.

Injection: Treating untrusted input as commands or executable instructions.

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

Secure development lifecycle: A development process integrating security throughout software delivery.

SAST: Testing that analyses source or intermediate code without executing the application.

DAST: Testing that evaluates a running application from an external perspective.

SBOM: An inventory of software components and dependencies.

Shared responsibility: Allocation of security duties between a cloud provider and customer.

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

MFA: Authentication using two or more independent factors.

Configuration drift: Unplanned divergence from an approved secure configuration.

OT: Technology that monitors or controls physical processes.

SCADA: Supervisory control and data acquisition systems used in industrial environments.

IoT: Network-connected physical objects with sensing, processing or control capabilities.

Secure boot: A process that permits only authenticated software to start.

Segmentation: Dividing systems or networks to restrict unnecessary communication.

SSRF: A flaw causing a server to make attacker-influenced requests to unintended destinations.

Data minimisation: Collecting and retaining only data necessary for a defined purpose.

Review Questions

Short Answer Questions

1. What is the difference between authentication and authorisation?
2. Identify two common causes of cloud security incidents.
3. Why should API authorisation be enforced on the server?
4. State two security challenges distinctive to OT environments.
5. What is the purpose of an SBOM?

Long Answer Questions

1. Explain five major OWASP application weaknesses and describe an appropriate control for each.
2. Discuss how security activities should be integrated across a secure development lifecycle.
3. Compare customer and provider responsibilities in IaaS, PaaS and SaaS.
4. Explain a secure architecture for a mobile application that processes sensitive data.
5. Discuss how IoT security requirements differ from those of conventional enterprise endpoints.

Analytical / Application Questions

1. An API validates that a user is logged in but allows the user to request any document by changing its identifier. Diagnose the weakness and propose a layered solution.
2. A factory wants to connect its legacy control network directly to the corporate network for convenience. Evaluate the risks and design a safer connectivity model.
3. A cloud administrator discovers that a storage service is publicly readable, but no evidence shows that files were downloaded. What should the organisation do immediately and during the subsequent investigation?

Multiple Choice Questions with Answers

Question 1

Which control most directly prevents a user from retrieving another customer’s record by changing an object identifier in an API request?

A. Client-side menu hiding

B. Server-side object-level authorisation

C. Increasing database storage

D. Disabling application logging

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

Question 2

What is the principal purpose of parameterised database queries?

A. To separate data from SQL instructions

B. To increase password complexity

C. To encrypt all database backups

D. To provide physical network segmentation

Correct Answer: A. To separate data from SQL instructions

Question 3

In a typical IaaS arrangement, which responsibility generally remains with the customer?

A. Physical security of the provider’s data centre

B. Maintenance of the provider’s hypervisor

C. Configuration of guest operating systems and identities

D. Manufacture of the provider’s servers

Correct Answer: C. Configuration of guest operating systems and identities

Question 4

Which statement best describes a secure development lifecycle?

A. Security is tested only after production release

B. Security activities are integrated from requirements through operation

C. Only external penetration testers are responsible for security

D. Security is limited to encrypting application data

Correct Answer: B. Security activities are integrated from requirements through operation

Question 5

Why are shared IoT device credentials a significant risk?

A. They improve individual accountability

B. They make device replacement impossible in every case

C. Compromise of one credential may affect many devices and users

D. They prevent all firmware updates

Correct Answer: C. Compromise of one credential may affect many devices and users

Question 6

Which practice is most appropriate for sensitive secrets in a mobile application?

A. Hard-code them in the application package

B. Place them in a public configuration file

C. Rely on client-side obfuscation alone

D. Keep sensitive authorisation decisions and secrets on protected server-side systems

Correct Answer: D. Keep sensitive authorisation decisions and secrets on protected server-side systems

Question 7

Why may passive monitoring be preferred to aggressive scanning in some OT environments?

A. OT systems never require security testing

B. Active scanning can disrupt fragile or safety-critical equipment

C. Passive monitoring automatically patches equipment

D. Scanning is prohibited on every industrial network

Correct Answer: B. Active scanning can disrupt fragile or safety-critical equipment

Question 8

Which cloud practice best reduces configuration drift?

A. Allowing each administrator to use personal settings

B. Using version-controlled infrastructure as code and policy checks

C. Disabling audit logs

D. Granting all administrators unrestricted permissions

Correct Answer: B. Using version-controlled infrastructure as code and policy checks

Question 9

What does SSRF allow an attacker to influence?

A. The physical temperature of a server room directly

B. Requests made by a server to unintended destinations

C. The encryption algorithm used by every browser

D. The manufacturing process of a device without network access

Correct Answer: B. Requests made by a server to unintended destinations

Question 10

Which statement about encryption and access control is correct?

A. Encryption eliminates the need for authorisation

B. Access control is unnecessary when TLS is used

C. Encryption protects data but does not determine which authenticated users may access it

D. Encryption prevents all insider threats

Correct Answer: C. Encryption protects data but does not determine which authenticated users may access it