Public website
The website uses encrypted HTTPS connections, browser security headers, input validation, bounded form fields, spam traps, and request rate limits. Public tools do not ask for passwords, OTPs, recovery codes, or private keys.
Access should be earned, limited, and reviewable.
Our public website, Learning Hub, internal editorial workspace, and client engagements have different risks. Each requires deliberate boundaries rather than a single broad promise.
Learning Hub profiles
New learners can use Google’s verified sign-in or activate an email-and-password account with a six-digit code. Google identity tokens are cryptographically verified for SecurityFirst.ng before access is granted. Email and Google identifiers are protected with keyed one-way hashes, verification attempts and sign-ins are rate limited, and the resulting HTTP-only device session lasts for normal return visits. Comment fields are bounded, same-origin protected, escaped before display, and rate limited. Account verification confirms control of an account or inbox, not legal identity.
Business enquiries
Enquiries are stored in the private database, are visible only to authorized administrators, and have a defined 180-day active retention period. The public form does not accept uploads.
Staff workspace
Staff access requires verified identity and explicit role assignment. Administrative, editorial, review, and publishing responsibilities remain separated, and sensitive actions create audit records.
Client environments
No access should be granted until scope, authorization, named users, authentication, logging, handling rules, and removal procedures are agreed. We use the minimum access reasonably needed for the approved work.
Vulnerability reporting
A dedicated monitored disclosure channel is still being established. Until it is published, do not perform disruptive testing or send sensitive vulnerability details through the assessment form. Contact hello@securityfirst.ng with a non-sensitive summary and request a secure reporting route.