# Security

This section describes the two security mechanisms most relevant to integrations:

1. Incoming signed verification URL (request integrity)
2. Outgoing signed result URL (result integrity)

These are independent features and can be enabled/used separately.

# Incoming signed verification URL (request integrity)

Some projects may require that the initial verification URL (the one your application sends the user to) is signed.

Purpose:

• prevent unauthorized tampering with query parameters before the verification starts
• ensure the verification session is initiated with an authentic, unmodified set of inputs

Integration guidance:

• treat the signing key as a secret
• sign URLs on a trusted system (typically your backend)
• do not generate signatures in browser JavaScript

If your project requires signed input and the signature is missing/invalid, the verification will be rejected.

# Outgoing signature on the result URL (result integrity)

The result redirect includes reSignature, which can be used for tamper detection.

• Signature validation is optional.
• If you need higher assurance, validate reSignature on your backend before trusting any other parameters.

Operational recommendations:

• consider all query parameters untrusted until signature verification passes
• validate on your backend (or another trusted environment)
• if verification fails, do not trust or persist the reported outcome

# Origin validation (for iFrame / Popup window)

In embedded scenarios, the VerifEye result page posts a message to the parent/opener.

Recommendations:

• always validate event.origin against the expected VerifEye domain(s)
• treat event.data.redirectedTo as untrusted input until you validate the URL with reSignature checking

---

Last updated: 2026-02-03