Security Best Practices Guide
Production guidance for securing facial authentication, face recognition login, liveness checks, PIN protection, domain restrictions, and webhook-backed account workflows with FACEIO.
Open the Application Manager to configure PIN Code validation, liveness checks, allowed domains, request-header validation, and webhook delivery.
Design Secure Facial Authentication From the Start
Configure the FACEIO Widget, fio.js, and your backend controls before enabling facial authentication for production users.
Secure the Complete Authentication Flow
Facial authentication is part of your account-access boundary. Treat FACEIO configuration, fio.js integration, liveness checks, PIN rules, domain restrictions, webhook validation, and account recovery as one production security model.
These practices address unauthorized Widget use, weak PIN choices, presentation attacks, repeated enrollment, and backend synchronization. Configure the FACEIO settings covered in this guide from the Application Manager on the FACEIO Console ↗.
Start with the Getting Started guide and fio.js Integration Guide, then use this page as your production security checklist before enabling face recognition login for real users. For implementation questions, use the community forum ↗ or open a private support request from the Console ↗.
Production Security Checklist
Before launching FACEIO facial authentication in production, verify that your application has a complete account-security path around the widget, not only a working client-side integration.
- Lock down origins: enable domain restrictions and reject missing Origin or Referer headers before exposing your Public ID.
- Keep liveness active: use face spoof protection for sensitive login, onboarding, account recovery, and step-up verification flows.
- Plan PIN behavior: decide when PIN confirmation is mandatory, how failed attempts are handled, and how account recovery works.
- Connect backend events: use FACEIO webhooks for enrollment, authentication, and Facial ID deletion events that affect account state.
- Protect enrolled users: document how your product handles Facial IDs, deletion, account unlinking, and suspicious authentication attempts.
- Review privacy controls: pair this page with the privacy best-practice guide before enabling enrollment for end users.
FACEIO Application Security Settings
Review each FACEIO security setting against your website or web app's login flow, recovery path, and backend authorization rules. Configure these options in the FACEIO Application Manager ↗.
Reject Weak PIN Codes During Enrollment
During enrollment, each user defines a PIN Code that FACEIO can request during authentication. Rejecting weak PIN Codes prevents common values from weakening this additional validation step.
- Reject common patterns such as
0000,1111, and1234. - Keep the PIN separate from passwords, phone numbers, dates of birth, or other profile data.
- Use PIN confirmation as a controlled step-up signal, not as a replacement for account recovery and server-side authorization.
If weak PIN rejection is enabled, users must choose a stronger code before enrollment can continue. Combine this setting with the PIN confirmation policy below for sensitive applications.
Prevent Same User From Enrolling Twice Or More
When enabled, this option checks whether the person appears to be enrolled already in the same FACEIO application. If a duplicate is detected, enrollment is aborted and the fioErrCode.FACE_DUPLICATION error code is raised to your host application. Duplicate detection is a recognition result, not a guarantee that every repeated enrollment will be identified. Keep this
option enabled for SaaS accounts, marketplaces, fintech onboarding, ecommerce fraud prevention, and any workflow where one person should map to one account or one Facial ID.
Liveness and Face Spoof Protection
Liveness setting: Enable this protection when presentation-attack detection is required by your authentication flow.
When activated, this feature helps counter presentation attacks from photos, printed images, replayed videos, mobile screens, masks, and similar spoofing attempts. No detection layer should be treated as a standalone guarantee, so your application should decide how to handle suspicious sessions. If a presentation attack is detected, FACEIO raises the
fioErrCode.PAD_ATTACK error code so your backend can deny access, retry safely, or route the session to review.
For biometric authentication in web and mobile apps, liveness detection should be part of the user journey and the backend risk decision. Do not treat a failed anti-spoofing result as a normal login error.
- Log the event server-side when it affects account access or fraud scoring.
- Avoid giving attackers detailed feedback about which anti-spoofing signal failed.
- Use webhooks and application monitoring to correlate repeated failures with suspicious account activity.
Pair anti-spoofing with domain restrictions, PIN policies, rate limiting, and a clear fallback path for legitimate users whose camera, lighting, or device conditions require another attempt.
Forbid Minors From Enrolling On Your Application
When activated, this option applies FACEIO's age-estimation result during enrollment and returns fioErrCode.MINORS_NOT_ALLOWED when the result falls below the configured minimum. Age estimation is probabilistic and should not be treated as an exact age or a guarantee of legal eligibility.
Activate this setting from the FACEIO Console ↗ only when an age estimate is an appropriate enrollment signal. Application owners remain responsible for required notices, consent, legal review, and any separate age or eligibility checks.
Always Ask for PIN Code During Authentication
Recommended for Sensitive Applications: Keep this option enabled for banking, fintech, admin portals, account recovery, payments, and other sensitive workflows.
During authentication, FACEIO can ask the user to confirm their PIN after face verification. If this option is turned off and the face match is clear enough for your configured policy, the session can continue without an additional PIN prompt.
If this option is enabled, the user must confirm their PIN before FACEIO completes authentication. After repeated invalid attempts, FACEIO aborts the flow and returns the appropriate error code. Your backend remains responsible for access, rate limiting, and account recovery decisions.
Enforce PIN Code Uniqueness Among Users
During enrollment, each user may define a PIN that is at least 4 digits and no more than 16 digits. If PIN uniqueness is enabled, FACEIO rejects a PIN that is already used by another enrolled user in the same application. This reduces the risk that a shared fallback value becomes a weak point in your facial authentication flow.
Ignore Obscured And Partially Masked Faces
By default, obscured faces, poor-lighting captures, and partially masked faces are discarded from the recognition process. FACEIO requests another frame until a clearly visible face is detected. Keep this behavior strict for production biometric authentication unless your application has a specific accessibility or operational reason to relax it.
Reject Missing or Empty Origin/Referer HTTP Request Headers
When enabled, this option rejects fio.js instantiation when the browser request is missing an Origin ↗ or
Referer ↗ header. Treat this as a baseline control against forged or abnormal requests, then use domain restrictions to limit where your application Public ID can be used.
Restrict Widget Instantiation To Authorized Domain Names Only
When enabled, this option restricts fio.js instantiation to the domain names you authorize. Other domains cannot use your application Public ID to start FACEIO enrollment or authentication. Configure the allowed domain list from the
Application Manager ↗ before production launch.
Restrict Widget Instantiation To Authorized Countries Only
When enabled, this option restricts fio.js instantiation to specific countries you define. Use it when your service is geographically limited, regulated by region, or exposed to abuse from locations where you do not operate. Configure allowed countries with ISO-3166-1 codes from the
Application Manager ↗.
Enable Webhooks
Webhooks let your backend receive events from the FACEIO Widget so your application records can stay synchronized with new-user enrollment, successful facial authentication, and Facial ID deletion.
Webhook Event Details
When an event occurs, FACEIO sends an HTTP POST request to the configured webhook URL. Depending on the event, the payload can include:
- The Unique Facial ID of the user in question
- Gender and age (in case of new enrollment)
- Timestamps, event type, IP information
- The linked payload when available
Learn More About Webhooks
Configure your webhook endpoint in the FACEIO Application Manager, then validate webhook events server-side before changing account state.
Configure FACEIO Security Controls
Before production, create an application, restrict its allowed domains, configure liveness and PIN Code validation, and verify the backend controls used by your flow.