Article 13
Designing security for web, mobile and APIs before production
A beginner-friendly guide to authentication, authorization, tokens, sessions, TLS, validation, rate limits, secrets, mobile storage and secure logging.
A common misunderstanding
Start with the people using the system
Hiding a button does not mean the API rejects the action
Web and mobile clients are controlled by the user. Requests can be inspected, changed or recreated outside the interface. Treat every client value as untrusted and re-check identity, authorization, data shape and business rules on the server. Changing an order ID must never reveal another customer's order, even to a valid logged-in user.
Terms before you begin
Technical language, explained by what each part does
You do not need to memorize every term. Use this section as a map while reading the detailed explanation.
- Authentication
- The process of proving identity using passwords, MFA, passkeys or SSO.
- Authorization
- The decision that an identity may perform an action on a specific resource.
- Session
- Server-side login state commonly referenced by a random cookie identifier.
- Access Token
- A short-lived credential presented to an API; it is not a password and should not be stored indefinitely.
- BOLA / IDOR
- An API flaw where login is checked but access to the requested object ID is not.
- Input Validation
- Checking type, size, format, range and business rules before using input.
- CORS
- A browser policy controlling which origins may read responses; it is not authentication and does not protect against mobile clients.
- Threat Model
- A structured view of assets, attackers, attack paths and mitigating controls.
Summary for business and everyday users
Designing security for web, mobile and APIs before production
Authentication identifies the caller; authorization decides whether this caller may act on this object. Both are required.
Mobile apps and browser JavaScript cannot permanently hide company secrets from device owners.
APIs validate input, rate-limit abuse, enforce object authorization and return only necessary data.
Security spans design, review, automated testing, dependency scanning, penetration testing and monitoring.
Interactive explanation
See how the stages connect before reading the detail
Select a stage to understand what happens, what evidence to inspect and how one decision affects the next stage.
Step 01 / 06
01 / Define trust boundaries
Treat browsers and mobile apps as external, even when we wrote them
Client code can be inspected and altered. Never embed database passwords, private API keys or critical rules only in the interface. Client validation improves usability; server validation enforces policy. Draw data flows and inspect every trust-boundary crossing for identity spoofing, tampering, disclosure, denial of service and auditability.
In-depth explanation
Work through each issue in real operating context
Each section connects business impact with what a Tech Lead needs to inspect, including examples, evidence and constraints.
01 / Define trust boundaries
01Treat browsers and mobile apps as external, even when we wrote them
Client code can be inspected and altered. Never embed database passwords, private API keys or critical rules only in the interface. Client validation improves usability; server validation enforces policy. Draw data flows and inspect every trust-boundary crossing for identity spoofing, tampering, disclosure, denial of service and auditability.
02 / Identity and access
02Successful login is only the beginning; every request still needs resource authorization
Use proven identity services and protocols, add MFA for higher risk, and control brute force. On every request, derive role, tenant and ownership from trusted server data rather than client claims. Validate token issuer, audience and expiry, or protect cookie sessions with HttpOnly, Secure, SameSite and CSRF controls.
BOLA example
GET /orders/8421
Do not only check for a token. Query within the caller's tenant/ownership scope and avoid revealing whether an unauthorized object exists.
03 / Input and output
03Define schemas, sizes and business rules, and return only necessary data
Validate requests with explicit schemas, size limits and business rules. Use parameterized data access and context-appropriate output encoding. Return purpose-built response objects rather than entire database models. Treat uploads as hostile, and expose safe error codes and request IDs instead of stack traces or secrets.
04 / Control abuse
04Rate limits should consider identity and operation cost, not IP alone
IP-only limiting harms shared networks and is easy to evade. Layer limits by account, API key, resource, operation cost and total capacity. Add timeouts, body limits, pagination, queues and idempotency for retried writes. Return useful 429 behavior and monitor patterns without logging secrets.
05 / Client-side storage
05Choose token storage by threat model; a mobile app cannot hide a permanent secret
Same-origin web apps often benefit from HttpOnly secure session cookies while still addressing CSRF and XSS. Mobile credentials belong in Keychain/Keystore with short lifetimes and safe logging/backup behavior. Certificate pinning requires a rotation plan. Any key shipped in an app is discoverable and cannot alone prove authenticity.
06 / Verify continuously
06A one-time pre-launch review cannot keep up with changing code and vulnerabilities
Define standards and abuse cases during design, review sensitive code, and run SAST, dependency, secret, container and infrastructure scans in delivery. Add dynamic API/mobile tests and risk-based penetration testing using OWASP ASVS, API Security and MASVS. In production, monitor identity anomalies and vulnerability advisories with severity-based patch SLAs.
Checklist before action
Model data flow and threats
Separate authentication and authorization
Check tenant/owner for every object
Use TLS everywhere
Define request/response schemas
Limit uploads and bodies
Layer rate limits
Use appropriate token/session lifetimes
Do not ship private secrets
Mask sensitive logs
Scan code, dependencies, secrets and IaC
Test against OWASP standards
Assign patch SLAs and incident owners
References
Figures and examples create a discussion framework. Validate them against the real system and its constraints before deciding.
- Reviewed by
- SIS Application Security
- Last reviewed
- 2026-07-17
Not sure where to start the review?
Use a preliminary tool or share the system context with SIS so the highest-priority work can be identified.