Strong access
Authentication, session duration, RBAC and least privilege are aligned with role and risk.
SECURITY & TRUST
Security starts with what a user must not be able to do.
Security-by-design means authentication, roles, data isolation, audit, secrets, sessions and deployment boundaries are considered during design. The goal is not “security” as a marketing label, but demonstrably smaller authority, less exposure and an understandable recovery path when something goes wrong.
function qavirio_process_contact_submission(
$source, $nonce_field, $nonce_action
) {
if ($_SERVER['REQUEST_METHOD'] !== 'POST'
|| empty($_POST[$nonce_field])) {
return ['sent' => false, 'error' => false];
}
if (!wp_verify_nonce(
sanitize_text_field(wp_unslash($_POST[$nonce_field])),
$nonce_action
)) {
return ['sent' => false, 'error' => true];
}
$name = sanitize_text_field(
wp_unslash($_POST['qv_name'] ?? '')
);
$email = sanitize_email(
wp_unslash($_POST['qv_email'] ?? '')
);
if (!$name || !is_email($email)) {
return ['sent' => false, 'error' => true];
}
}SECURITY-BY-DESIGN
Four principles with concrete technical consequences.
Implementation depends on risk and context. A public marketing website needs something different from a platform holding personal data. But the same discipline applies: limit authority, minimise data, reconstruct relevant events and fail safely when uncertain.
Minimal data
Process and store locally only the data needed for the function, with clear boundaries around storage and access.
Traceability
Make important actions and changes reviewable without unnecessarily duplicating sensitive content in logs.
Fail closed
When uncertain, access has expired or state is invalid, never silently grant more authority.
IDENTITY & ACCESS
An authenticated user is not yet an authorised user.
Authentication answers who someone is or which account is being used. Authorisation then answers a different question: which action may that identity perform in this context? That separation is essential in systems with multiple roles, sensitive records or administrative functions.
We therefore do not rely on navigation or visibility alone to enforce rights. Hiding a button is not security. The server or application layer should enforce authority again. For mobile access or sensitive contexts, shorter sessions, reauthentication and remote revocation may be appropriate.
Who are you?
Strong sign-in and session policy appropriate to risk and usage.
What may you do here?
RBAC and context checks limit actions to explicitly granted authority.
Access must be able to end
Sessions or devices should be revocable after loss, role change or incident where the context requires it.
DATA BOUNDARIES
Not everything technically reachable should be available.
Data minimisation is not just about collecting fewer fields. It is also about which subset each role needs, which information may remain locally on a device, how long data remains relevant and whether the same information is unnecessarily duplicated in logs, exports or caches.
In multi-tenant or sector-specific software, boundaries between organisations or records should be technically enforceable. A query, API or background task should not silently look outside the intended context. Context, ownership and permissions therefore belong in the data model and application layer.
Only what the task needs
UI, API and storage are limited to relevant information.
Boundaries between records or tenants
Context should be reflected in queries, services and authorisation.
Retain for a reason
Retention and deletion are aligned with purpose, obligation and product context.
SECRETS, TRANSPORT & CONFIGURATION
Credentials do not belong in source code. Sensitive data should not cross insecure boundaries unnecessarily.
Application code and environment configuration are separated where practical. API keys, passwords and tokens belong in appropriate secret/configuration mechanisms and should not end up in repositories, public JavaScript or screenshots. Transport between browser, application and external services should use TLS where confidentiality or integrity requires it.
Dependencies and platform versions are also part of security hygiene. Updates are not installed blindly, but known vulnerabilities or obsolete components should not remain indefinitely either. The balance is controlled patching with regression checking.
Outside public code
No credentials in templates, repositories or client-side bundles.
Protect transport
HTTPS/TLS for production communication where confidentiality or integrity matters.
Update deliberately
Combine security updates with compatibility and regression checks.
AUDIT & OBSERVABILITY
Log what is needed to reconstruct behaviour — not everything you can collect.
Audit logging is most useful when important events are defined: login, privilege change, status transition, critical write, export, configuration change or deployment. A useful trail tells who or which system acted, when, in what context and with what result.
A log can itself become sensitive. We therefore avoid full documents, tokens, passwords or unnecessary personal data in logs where practical. Observability should provide enough context to understand incidents and errors without creating a second uncontrolled data source.
Actor and action
The relevant identity or service and the action performed.
Where and under what scope
Tenant, record, workflow or system context where relevant.
Outcome visible
Success, denial or error status so behaviour remains explainable.
FAIL CLOSED & RECOVERY
A failure should never automatically result in more authority.
When authentication, policy, integration or configuration is uncertain, critical functions should fail safely where appropriate rather than continue on a “best effort” basis. A timeout to an external service should not silently be interpreted as permission. An expired session should not gain a hidden bypass for convenience.
Security also includes recovery: revoke an account or device, correct configuration, roll back a service, restore a backup, reconstruct an incident and then check whether the same cause can recur. Availability and security meet directly here.
- Uncertain authorisation → deny, do not guess.
- Incident → be able to revoke access and restore state.
- Recovery → re-check cause and regression.
No absolute security claim. Concrete controls, yes.
Security is a continuous process of bounding, checking, patching, testing and recovery. We only claim formal assurance or certification when it actually exists.
NEXT STEP
Contact →What should work better digitally?
Describe the problem. We look at goals, users and process first — technology comes second.