423.32 Sandboxing and abstraction
Learn how sandboxing and abstraction are used in real-world systems like iPadOS to enforce security, limit exposure, and protect user data.
Targets
Define sandboxing and abstraction in the context of secure system architecture
Understand how iPadOS uses these concepts to isolate risk and protect users
Identify how these techniques support security by design in mobile operating systems
Syllabus references
What is sandboxing?
Sandboxing is the practice of running code in a restricted environment that limits what it can access or do. A sandbox isolates the code so that even if it is buggy or malicious, it can’t affect the rest of the system.
In iPadOS:
Apple’s iPadOS uses per-app sandboxing to restrict what each app can access:
Each app runs in its own isolated container
Apps cannot read or write data from other apps
Apps must request permission to access sensitive features like the camera, microphone, or location
Files saved by one app are invisible to others unless shared intentionally
This model protects the user from apps that try to overstep their boundaries and reduces the damage caused by bugs or malware.
What is abstraction?
Abstraction hides internal complexity, exposing only what is necessary. It simplifies the interaction between developers and users, and reduces the risk of misuse.
In iPadOS:
Abstraction is used throughout the system:
Apps interact with hardware (e.g. camera, Bluetooth) only through secure, high-level APIs
The file system is abstracted so users don’t see system-level files or app internals
Developers can only access frameworks that Apple exposes — internal system operations are hidden
This protects system integrity and encourages secure app development.
Sandboxing and abstraction in secure system design
In iPadOS, sandboxing and abstraction are integral to Apple’s security-by-design philosophy. They protect the system even when apps misbehave or are compromised.
Sandboxing
Each app runs in its own container with no access to system or other app data by default
Abstraction
Apps access system resources only through controlled APIs; complex internals are hidden
These design choices uphold the principles of least privilege, separation of concerns, and defence in depth — all core to secure software architecture.
iPadOS vs desktop OS: Sandboxing and abstraction
Sandboxing by default
Every app is sandboxed automatically
Most apps have full access unless sandboxed explicitly
File system access
App has access only to its own files (containerised)
Apps can access most file paths unless restricted by permissions
Inter-app communication
Strictly controlled (e.g. via share sheets or specific APIs)
Freer communication between apps and shared system resources
System APIs
Only exposed through predefined, secure frameworks
Developers often have access to low-level system functions
Permissions model
App must request explicit user consent (e.g. location, camera)
Many features do not require user consent unless gated by system
Default execution model
Apps cannot run in the background indefinitely or start other processes
Apps can run background services, daemons, or interact with hardware freely
User exposure to system internals
Highly abstracted – users don’t see system folders or app binaries
Users can browse system files, install scripts, or modify settings
Update and patching model
Controlled, secure, system-level updates from Apple
Varies by OS; patching may be optional or fragmented
Summary
Sandboxing restricts what code or apps can access, protecting users and the system
Abstraction hides complexity, reducing the chance of accidental or malicious misuse
iPadOS is a clear example of both principles applied at the operating system level to enforce secure behaviour by default
Last updated
Was this helpful?