The Web Scanner SDK captures a passport or ID card in the end user's browser and returns the recognized data to the client's web page; the OCR API receives a document image from the client's backend and returns the recognized data in the response. Both use the same recognition pipeline. Misfora processes each document image only in memory for the duration of a single request and does not store document images or recognized document data. Misfora holds no security certifications (such as ISO 27001 or SOC 2); this page describes the measures actually in place.
1. Data flow
- The client's backend creates a short-lived SDK session token with its secret API key (
POST /v1/sdk/session). - The SDK runs in the end user's browser. Document detection and image-quality checks run on the device; the camera stream and intermediate frames are not sent to Misfora.
- One image per attempt — the captured frame or a photo uploaded by the user — is sent over HTTPS to
POST /v1/scan. - The image is recognized by Misfora's own OCR pipeline on servers in the EU (Railway, EU West — Amsterdam, Netherlands). Images are not sent to third-party OCR or AI services.
- The recognized fields are returned to the browser and passed to the client's page through a callback. The client decides what to store and where.
With the OCR API, the client's backend sends the image directly to POST /v1/scan with its secret API key and receives the result in the response; steps 1–2 do not apply.
2. Data handled
| Data | Where | How long |
|---|---|---|
| Document image | Server memory only, during one request | Discarded when the request ends |
| Recognized fields (name, document number, dates, nationality, etc.) | Server memory only, then in the response | Discarded when the request ends |
| Request metadata: time, client company, request ID, SDK session ID, document type, recognition engine, processing time, review flag, capture method, file size, error code | Misfora database (EU) | 12 months, plus up to 27 days in backups |
| SDK session: hash of the token, allowed document types, attempt counter, expiry | Misfora database (EU) | 12 months after expiry, plus up to 27 days in backups |
| Client IP address and request time | Hosting provider logs (Railway, stored in the US) | Up to 90 days, set by the provider |
Document images, recognized text and identifying document fields are not written to application logs. Request metadata is kept to a minimum but may, combined with the client's own data, relate to an individual, and is treated as personal data.
A fallback recognition step may write the image to a short-lived temporary file inside the application container; the file is deleted automatically before the response is returned, including when processing fails. The container file system is not persistent and is cleared on every restart and deployment.
3. Encryption
All communication between the SDK or the client's backend and the Misfora API uses HTTPS (TLS). Plain HTTP requests are redirected to HTTPS at the hosting provider's edge and are never processed by the application; the application additionally rejects API requests that reach it over HTTP. HSTS is enabled for misfora.com. TLS is terminated at the hosting provider's edge.
According to the hosting provider's Data Processing Agreement (Exhibit C), databases are encrypted at rest and traffic within the provider's infrastructure is encrypted (WireGuard). Encryption keys for the database are managed by the hosting provider.
4. Authentication and session tokens
- Client API keys are stored only as Argon2id hashes. A key is shown once at creation through a one-time setup link and cannot be recovered, only reissued.
- SDK session tokens are stored only as SHA-256 hashes. A token is valid for 1–15 minutes and allows at most 10 image submissions, for the document types the client allowed.
- A token stops working permanently when it expires or its attempts are used up; it cannot be extended. Attempts are consumed atomically in the database when an image is accepted, before recognition, so concurrent requests cannot exceed the limit.
- For requests with an SDK token, the API checks the
Originheader server-side against the websites registered for the client; requests from unregistered origins or without anOriginheader are rejected. Origin validation limits where a token can be used from a browser but is not treated as authentication: authentication relies on the secret API key, which never leaves the client's backend, and on the short-lived token.
5. Abuse and input protection
- Per-client rate limits (requests per minute and per day) and a monthly quota. Scans made with SDK tokens count against the issuing client's limits. Server-wide concurrency limits protect the service from overload.
- Accepted formats: JPEG, PNG, HEIC. Limits: 10 MB per file, 50 megapixels per image; images above 13 megapixels are downscaled. Requests with a body larger than 12 MB are rejected before the body is read. Decompression-bomb images are rejected. PDF files are not accepted.
- Files are validated by decoding them. Truncated or corrupted images are rejected before recognition, so incomplete image data never reaches the OCR pipeline.
- Uploaded images are held in memory and are not written to disk by the web framework.
- Malformed requests produce a controlled API error without affecting other requests.
6. Infrastructure and access
- Application, database and database backups run on Railway in the EU West region (Amsterdam, Netherlands). The production database is not exposed to the public internet and is reachable only from the application over the provider's private network.
- DNS is provided by Cloudflare without proxying; SDK traffic does not pass through Cloudflare.
- Application secrets (database credentials, provider keys, encryption keys) are stored as environment variables in the hosting platform and are not present in source code or the code repository. Source code is kept in a private GitHub repository.
- Administrative access to hosting, database, logs, DNS, email provider and code repository is restricted to a single administrator. Multi-factor authentication is enabled on all these accounts. No other person has standing access; a documented emergency-access procedure lets a designated trusted person obtain credentials only to maintain service continuity if the administrator is unavailable. The procedure is tested at least once a year, every use of emergency access is recorded, and all affected credentials are changed afterwards.
- Database backups are created automatically by the hosting provider: daily (kept 6 days) and weekly (kept 27 days).
7. Vulnerability and dependency management
- Dependencies are pinned and reviewed monthly. Automated audits (pip-audit) of the full installed environment, including transitive packages, run on every dependency change and weekly. GitHub Dependabot alerts and security updates are enabled.
- The application container and system packages are rebuilt on every deployment.
- Vulnerabilities are prioritized by severity: critical issues are assessed immediately and remediated or mitigated with a target of 7 days after a fix becomes available; high-severity issues are assessed within 7 days; other issues are addressed in the monthly review. Components that decode uploaded images have the highest priority.
8. Monitoring and incident response
- Hosting-platform alerts for crashes and failed deployments; external uptime monitoring of the API and SDK endpoints every 5 minutes; hourly automated checks of the API/SDK request log for anomalies (invalid credentials, requests from unregistered websites, rate-limit rejections, recognition errors, malformed uploads); daily review of service statistics.
- Misfora notifies affected clients no later than 24 hours after becoming aware of an incident affecting their data. Details: Incident Response Policy.
- Security issues can be reported to security@misfora.com (see /.well-known/security.txt).
9. Client responsibilities
- Keep the secret API key on the backend; issue SDK tokens only to authenticated users of the client's service, with the minimum attempts and lifetime needed.
- Register only the client's own websites as allowed origins.
- Validate or reprocess results on the backend where server-side trust is required.
- Inform end users and establish the legal basis for processing; decide how long recognized data is kept.
- Use
https://for all direct API calls; keep the API key out of browsers and mobile apps.
A Data Processing Agreement for the Web Scanner SDK and OCR API is available on request: partners@misfora.com. Report security issues to security@misfora.com. See also the Privacy Policy.