QAing · Security Principles for QA Engineers

Security is not a binary property. A system is not simply “secure” or “insecure”: security depends on the assets being protected, the adversaries that may target them, the controls in place and the business impact if those controls fail. For QA engineers, security principles provide a practical framework for identifying risks, designing negative tests and checking that systems fail safely.

On this practical guide

CIA triad DAD triad Security models Defence in depth ISO/IEC 19249 Zero Trust Threat & risk Shared responsibility QA applications Checklist

Security starts with the adversary

Before choosing controls, ask what you are protecting and from whom. The protection needed against an accidental user action is very different from the protection needed against organised crime, insider abuse or industrial espionage.

Asset

What has value? Data, credentials, money, intellectual property, availability, infrastructure or reputation.

Adversary

Who may attack it? Opportunistic attackers, insiders, organised groups or highly capable targeted actors.

Attack path

How could the asset be reached? APIs, identities, dependencies, infrastructure, browsers or social engineering.

Impact

What happens if the attack succeeds? Disclosure, fraud, downtime, regulatory exposure, safety impact or loss of trust.

Perfect security does not exist. Security engineering aims to reduce risk, make attacks harder, limit blast radius and improve detection and recovery.

The CIA triad

The CIA triad is one of the most useful ways to describe security requirements: Confidentiality, Integrity and Availability.

Property	Meaning	QA question
Confidentiality	Only authorised users and systems can access information.	Can a user access data outside their permissions or tenant?
Integrity	Information remains correct and unauthorised alteration is prevented or detected.	Can data be changed without the right permissions or validation?
Availability	Systems and information remain accessible when required.	Does the service remain usable during failure, restart or overload?

Online shopping example

Confidentiality: payment details should only be visible to authorised payment-processing systems.
Integrity: prices, quantities and delivery addresses must not be silently altered.
Availability: customers should be able to browse and purchase when the service is expected to operate.

Healthcare example

Confidentiality: unauthorised users must not access medical records.
Integrity: diagnoses, prescriptions and patient history must not be altered improperly.
Availability: clinicians need access to relevant records when making treatment decisions.

The three priorities are contextual. A public announcement may require little confidentiality but very strong integrity. A clinical system may require extremely high integrity and availability at the same time.

Beyond CIA

Authenticity

Authenticity answers: Is this user, message, file or transaction genuinely from the claimed source? Examples include verifying an API caller, validating a signed software package or proving that an order came from the claimed customer.

Non-repudiation

Non-repudiation provides evidence so that a party cannot plausibly deny performing an important action. Digital signatures, trusted audit trails and signed transactions may contribute to this requirement.

Parkerian Hexad

The Parkerian Hexad extends CIA with three additional ideas:

Element	Meaning
Authenticity	The source or identity is genuine.
Possession / Control	The rightful owner retains control of the information.
Utility	The information remains usable for its intended purpose.

If an encrypted backup disk is stolen, confidentiality may still hold while possession has been lost. If the disk remains physically available but the decryption key is permanently lost, the information has lost utility.

The DAD triad

DAD describes the opposite of CIA and is a useful way to think like an attacker:

Attack	Opposes	Example
Disclosure	Confidentiality	Customer records are stolen and published.
Alteration	Integrity	An attacker changes an invoice, balance or medical record.
Destruction / Denial	Availability	Data is deleted, encrypted or the service is made unreachable.

Turn a requirement into attack-oriented tests

Requirement:
Only the account owner can view an invoice.

Property:
Confidentiality.

DAD question:
How could the invoice be disclosed?

Tests:
- Change the invoice ID.
- Call the API directly.
- Remove or alter the token.
- Reuse another user's identifier.
- Test cached content after logout.

Foundational security models

Bell–LaPadula: confidentiality

Rule	Meaning
No read up	A lower-clearance subject cannot read higher-classification information.
No write down	A higher-clearance subject cannot write sensitive information into a lower-classification object.

Memory aid: read down, write up.

Biba: integrity

Rule	Meaning
No read down	A high-integrity subject should not trust lower-integrity information.
No write up	A lower-integrity subject should not modify higher-integrity information.

Memory aid: read up, write down.

Clark–Wilson: controlled integrity

Concept	Meaning
CDI	Constrained Data Item: protected data whose integrity must be preserved.
UDI	Unconstrained Data Item: input that is not yet trusted.
TP	Transformation Procedure: an authorised operation that changes protected data.
IVP	Integrity Verification Procedure: checks that protected data remains valid.

QA connection: Clark–Wilson maps well to modern applications: user/API input starts untrusted, application logic performs controlled transformations and validation confirms that protected business data remains consistent.

Defence in depth

Defence in depth means using multiple meaningful security layers so that one control failing does not automatically lead to full compromise.

Internet
   ↓
Edge protection
   ↓
Authentication
   ↓
Authorisation
   ↓
Input validation
   ↓
Service permissions
   ↓
Database permissions
   ↓
Encryption / monitoring / backups

Example: protecting customer records

MFA protects account access.
RBAC limits permitted actions.
API authorisation validates ownership.
The database identity has restricted privileges.
Encryption protects data in transit and at rest.
Audit logs record sensitive operations.
Monitoring detects suspicious extraction behaviour.

ISO/IEC TS 19249 architectural principles

ISO/IEC TS 19249 provides architectural and design principles for secure products, systems and applications.

1. Domain separation

Separate related components into security domains with defined privileges and boundaries. Examples include production vs test, public vs internal services and administrative vs normal-user functionality.

2. Layering

Structure systems into levels with clear responsibilities so security policies can be enforced and validated at multiple layers.

3. Encapsulation

Protect internal state behind controlled interfaces.

// Controlled behaviour
account.withdraw(100)

// Riskier direct mutation
account.balance = account.balance - 100

4. Redundancy

Use additional components or copies to preserve availability and, in some designs, integrity. Examples include database replication, backups, redundant power and multiple application replicas.

5. Virtualisation

Virtualisation provides isolation boundaries and controlled execution environments. Today this includes virtual machines, containers and cloud sandboxing techniques.

ISO/IEC TS 19249 design principles

1. Least privilege

Give users and services only the permissions necessary for their task.

Sales user:
✓ View products
✓ View prices
✗ Change prices
✗ Manage users
✗ Read payroll
✗ Access production database

2. Attack surface minimisation

Remove unnecessary services, routes, ports, permissions, dependencies and functionality.

QA examples

Verify unused admin endpoints are not exposed.
Check debug functionality is disabled outside approved environments.
Verify unsupported HTTP methods are rejected.
Look for unnecessary public ports and cloud endpoints.

3. Centralised parameter validation

Validate untrusted input consistently before processing it: forms, query parameters, JSON payloads, headers, file uploads and messages from other systems.

4. Centralised general security services

Where appropriate, centralise identity, authentication, authorisation, key management and auditing rather than implementing incompatible security logic in every component.

Centralised does not have to mean a single point of failure. A logically central security service can still be deployed redundantly.

5. Prepare for errors and exceptions

Systems should fail safely when dependencies, databases or network connections fail.

Do not bypass security when a permission check fails.
Do not expose stack traces, credentials or internal topology.
Keep business data consistent after interrupted operations.
Return safe user-facing errors while retaining useful server-side diagnostics.

Fail-safe defaults

Failure	Unsafe behaviour	Safer behaviour
Authorisation service unavailable	Allow access because permission cannot be checked.	Deny the protected operation or enter a deliberately designed degraded mode.
Role missing	Assume administrator.	Grant no privileged access.
Signature invalid	Process the message anyway.	Reject or quarantine it.
Firewall policy failure	Allow all traffic.	Fail closed.

Trust but Verify

This principle accepts operational trust while still requiring evidence that the trusted entity behaves correctly.

Verification may include audit logs, access reviews, anomaly detection, proxy inspection, intrusion detection and policy monitoring.

Zero Trust

Zero Trust removes implicit trust based on network location, device ownership or being “inside” the enterprise network.

Practical shorthand: never grant trust implicitly; verify access according to identity, context, policy and risk.

Zero Trust in practice

Authenticate users and services before access.
Authorise access to each protected resource.
Use least privilege.
Do not trust a request merely because it comes from an internal IP address.
Limit lateral movement.
Continuously evaluate security-relevant signals.

Microsegmentation

Microsegmentation reduces the size of network trust zones so compromise of one workload does not automatically grant unrestricted access to others.

QA scenarios

Valid user but wrong role.
Valid user with expired session.
Internal-network request without authentication.
Service identity attempts to call an unauthorised service.
Privileges change while a session is already active.

Vulnerability, threat and risk

Term	Meaning	Example
Vulnerability	A weakness.	An API does not check object ownership.
Threat	A potential source or mechanism of harm.	An attacker changes an invoice ID to access another customer's record.
Risk	The likelihood and business impact if the threat materialises.	Exposure of financial records and resulting regulatory/reputational damage.

Simple model:

Risk ≈ Likelihood × Impact

Risk questions for testers

Is the feature public or internal?
What privileges does the affected identity have?
Does it process personal, health, financial or authentication data?
How easy is the weakness to exploit?
What is the blast radius?
Would monitoring detect abuse?
Can the damage be reversed?

Shared Responsibility in the cloud

Cloud providers and customers both have security responsibilities. The exact boundary depends on the service model.

Model	Provider manages more of	Customer manages more of
IaaS	Physical infrastructure and virtualisation platform.	OS, applications, identities, configuration and data.
PaaS	Infrastructure, operating platform and runtime.	Application code, identities, app configuration and data.
SaaS	Infrastructure, runtime and application operation.	User access, tenant configuration and organisation-specific data controls.

Managed does not mean automatically secure. A cloud provider may operate its platform securely while the customer still exposes data through weak IAM, unsafe application code or incorrect configuration.

Translate security principles into QA tests

Confidentiality

Test authorisation, tenant isolation, sensitive fields, logs, exports and browser storage.

Integrity

Test validation, unauthorised updates, business invariants and transaction consistency.

Availability

Test dependency failure, timeouts, retries, restarts and degraded operation.

Least privilege

Build a role/action matrix and verify both allowed and denied operations.

Defence in depth

Verify bypassing one layer does not automatically expose the asset.

Zero Trust

Test resource access independently of network location or previous trust.

Broken object-level authorisation

Given:
User A owns order 100
User B owns order 101

Test:
Authenticate as User A
GET /api/orders/101

Expected:
403 or 404
No User B data returned

Privilege escalation

PATCH /api/users/me
{
  "role": "admin"
}

Expected for normal user:
Request rejected
Role unchanged

Fail-safe error handling

Scenario:
Permission service times out

Expected:
Protected action is not executed
No access granted by default
Safe response returned
Useful server-side diagnostics recorded

Security testing across the lifecycle

Stage	Useful security activities
Requirements	Identify sensitive assets, CIA priorities, roles and abuse cases.
Design	Review trust boundaries, privileges, data flows and failure behaviour.
Development	Unit tests for validation, authorisation and secure defaults.
API testing	Authentication, object ownership, manipulation and error handling.
UI testing	Role visibility, browser storage, sessions and sensitive data.
CI/CD	Dependency scanning, secret scanning, SAST and security regression.
Environment	TLS, IAM, secrets, exposed services and configuration.
Production	Monitoring, audit logging, incident response and recovery.

Security is not only penetration testing

Threat modelling.
Secure requirements.
Code review.
Static analysis.
Dependency and secret scanning.
Automated security regression.
API abuse testing.
Configuration review.
Resilience testing.
Manual penetration testing.

The earlier a security rule can be checked reliably, the cheaper it is to maintain.

Common security-testing mistakes

Mistake	Better approach
The button is hidden, so access is blocked.	Call the protected API directly and verify server-side authorisation.
Only happy paths are tested.	Add invalid, unauthorised and adversarial scenarios.
Client-side validation is trusted.	Bypass the browser and test the API directly.
Only one role is tested.	Use a role/action matrix.
Production credentials are used in QA.	Use dedicated least-privilege test identities.
Tokens appear in logs.	Mask sensitive values.
Internal network equals trusted.	Verify identity and authorisation at protected resources.
Failure paths are ignored.	Test unavailable dependencies, exceptions and timeouts.

Build a permissions matrix

Action	Customer	Support	Admin
View own profile	Allow	Limited	Allow
View another customer	Deny	Limited	Allow
Change own email	Allow	Deny	Allow
Change account role	Deny	Deny	Allow
Export all customer data	Deny	Deny	Restricted

Automate stable permission rules at the API layer whenever practical.

Security logging

Logging supports verification, investigation and accountability, but logs are security-sensitive assets themselves.

Useful events

Successful and failed authentication.
Password or MFA changes.
Privilege changes.
Administrative operations.
High-value data exports.
Repeated authorisation failures.

Do not log

Passwords.
Raw session/authentication tokens.
Private cryptographic keys.
Full payment-card details.
Unnecessary health, personal or financial information.

Security Principles QA checklist

Assets and sensitive data are identified.
Likely adversaries and abuse cases have been considered.
CIA requirements are explicit.
Authentication and authorisation are tested separately.
Object ownership is enforced server-side.
Every role follows least privilege.
Client-side restrictions are backed by server-side controls.
Invalid and malicious input is rejected safely.
Unused services and endpoints are minimised.
Sensitive data is absent from logs and unsafe URLs.
Error paths fail safely.
Dependency failure behaviour is defined.
Critical services have suitable redundancy and recovery.
Audit events exist for security-sensitive actions.
Internal network location is not treated as sufficient trust.
Sessions and tokens expire and invalidate correctly.
Secrets differ between QA and production.
Test accounts use least privilege.
Vulnerabilities are prioritised using likelihood and impact.
Cloud-provider and customer responsibilities are understood.
Security regression is automated where practical.
Automated checks are complemented by exploratory and penetration testing.

Security principles cheat sheet

Concept	Remember
CIA	Confidentiality, Integrity, Availability.
DAD	Disclosure, Alteration, Destruction/Denial.
Authenticity	Is the claimed source genuine?
Non-repudiation	Can the source later deny the action?
Parkerian Hexad	CIA + Authenticity + Possession + Utility.
Bell–LaPadula	Confidentiality: no read up, no write down.
Biba	Integrity: no read down, no write up.
Clark–Wilson	Integrity through controlled transformations.
Defence in depth	Use multiple meaningful protection layers.
Least privilege	Grant only what is required.
Attack surface minimisation	Remove unnecessary exposure.
Zero Trust	No implicit trust based on location or ownership.
Vulnerability	A weakness.
Threat	A potential source or mechanism of harm.
Risk	Likelihood and impact.
Shared Responsibility	Cloud provider and customer each own security responsibilities.

Useful links

ISO/IEC TS 19249:2017 ↗ — architectural and design principles for secure products, systems and applications.
NIST SP 800-207: Zero Trust Architecture ↗ — foundational guidance on Zero Trust.
NIST SP 800-207A ↗ — Zero Trust access control for cloud-native applications.
OWASP Top 10 ↗ — major web-application security risks.
OWASP API Security ↗ — common API security risks and guidance.
OWASP Cheat Sheet Series ↗ — practical secure-development guidance.