Security Foundations

Security as a Property, Not a Feature

Security is not something you add at the end of development or enable via a toggle.
It is an emergent property of how a system is designed, implemented, deployed, and operated.
A system is secure only insofar as its weakest assumptions hold.

Thinking of security as a feature leads to patching symptoms.
Thinking of security as a property forces you to reason about architecture, data flow, and failure modes.
This shift in mindset is foundational.

Trust, Assumptions, and Boundaries

Every system is built on assumptions.
Security work begins by identifying which assumptions are unsafe.

Trust boundaries exist wherever data, identity, or control crosses between components with different trust levels.
Common examples include:

• User input entering the backend
• Browser code interacting with APIs
• One service calling another
• External dependencies being executed

Security failures often occur when trust boundaries are implicit rather than explicit.
Make boundaries visible, then defend them deliberately.

The Attacker Model

Security cannot be reasoned about without defining attackers.
An attacker is not necessarily highly skilled or well-funded.

Common attacker capabilities include:

• Controlling input data
• Replaying requests
• Modifying client-side code
• Observing network traffic
• Automating interactions at scale

Avoid designing defenses against a single attacker profile.
Systems are broken by attackers who combine capabilities creatively.

Data Flow Over Code Flow

Security analysis should prioritize data flow over control flow.
Ask where data originates, where it moves, and where it is interpreted.

Danger arises when:

• Data is reinterpreted as code
• Identity data is reused without revalidation
• Trusted metadata is derived from untrusted sources

Mapping data flow exposes risks that code-level review often misses.
This is especially critical in web applications and distributed systems.

Authentication as Identity Establishment

Authentication answers a single question:
“Who is making this request?”

Common authentication mechanisms include:

• Password-based login
• Token-based authentication
• Certificate-based identity
• Federated identity systems

Authentication should be:

• Explicit
• Verifiable
• Short-lived when possible

Authentication alone provides no permissions.
Confusing authentication with authorization is a foundational error.

Authorization as Permission Enforcement

Authorization answers:
“What is this identity allowed to do?”

Authorization must be:

• Checked on every relevant request
• Enforced server-side
• Based on verified identity, not user input

Failures in authorization are often logic bugs rather than technical ones.
They are also among the highest-impact vulnerabilities.

Sessions, Tokens, and State

Sessions represent continuity of identity across requests.
They may be stateful (server-stored) or stateless (token-based).

Key properties to reason about:

• Lifetime
• Revocation
• Scope
• Storage location

Tokens are not inherently safer than sessions.
They merely shift responsibility to different parts of the system.

The Browser Security Model

Browsers enforce their own security rules, independent of server intent.
Understanding these rules is non-optional for modern security work.

Core concepts include:

• Same-Origin Policy
• Cookie scoping
• Credentialed requests
• Script execution contexts

Many web vulnerabilities arise from misunderstanding browser behavior rather than backend logic.
Always reason from the browser’s perspective.

Input Is Not the Enemy — Interpretation Is

User input is not dangerous by default.
Input becomes dangerous when interpreted in an unsafe context.

Examples include:

• HTML rendering
• SQL queries
• Command execution
• Template expansion

Security depends on controlling interpretation, not merely rejecting input.
This distinction underlies many injection vulnerabilities.

Cryptography as a Tool, Not a Solution

Cryptography provides primitives, not guarantees.
Misused cryptography is often worse than none at all.

Engineers must understand:

• What problem a primitive solves
• What assumptions it requires
• What it does not protect against

Avoid designing cryptographic protocols.
Prefer established constructions and libraries with clear threat models.

Secrets and Sensitive Material

Secrets include:

• Passwords
• API keys
• Tokens
• Encryption keys

Security failures frequently stem from poor secret handling rather than algorithmic flaws.
Secrets should be minimized, isolated, rotated, and audited.

Exposure is often operational, not technical.

Failure Is Inevitable — Design for It

Assume controls will fail.
Assume credentials will leak.
Assume bugs will ship.

Good security design limits blast radius and enables recovery.
This includes monitoring, alerting, and revocation paths.

Resilience is as important as prevention.

Security as Continuous Work

Security is not a milestone.
It evolves with system complexity, threat landscape, and operational scale.

Practices that help:

• Regular threat modeling
• Reviewing past incidents
• Keeping dependencies updated
• Learning from failures

Security maturity grows through iteration, not checklists.

Foundational Takeaways

Security begins with clear assumptions and explicit trust boundaries.
Identity and permission must be treated as separate concerns.
Data flow analysis reveals more than code inspection alone.

Understanding the platform you build on is mandatory.
Strong foundations prevent entire classes of vulnerabilities before they appear.