FAQ — Security
Frequently asked questions about how Survanta protects your data and secures the platform.
Q: How is my data protected from other organizations?
Survanta combines EF Core tenant query filters with explicit tenant/ownership checks on sensitive services and controllers. Tenant-owned surveys, responses, users, files, tokens, and integration clients are queried with a tenant boundary. This is defense in depth; avoid the absolute claim that every table has a non-null tenant key or that query filters alone prove isolation.
Q: Who can access my organization's data?
Within a tenant, server-side permission checks and resource ownership govern access. Platform users need the relevant system permission and, for tenant-scoped operations, a validated selected-tenant path or explicit platform workflow. Public tokens and scoped integration keys intentionally grant narrowly bounded external access. Do not infer that every Platform Admin read is universally audited unless the specific workflow records that audit.
Q: What happens if my API key is compromised?
Revoke or rotate the integration client immediately from the tenant Integrations area. Rotation invalidates the old key and displays the replacement once, with no overlap period. Update every consumer promptly and inspect that client's paged API-call audit records; successful authentication records LastUsedAt and an ApiCall before scope enforcement.
Q: Are uploaded files scanned for safety?
Tenant file-pipeline uploads validate configured extension, declared content type, content signature, and size, then may compress and encrypt before storage. This is content validation, not proof of antivirus/malware scanning, and owner-scoped paths can have different plan-quota behavior. Do not describe every upload mechanism as malware-scanned unless a scanner is actually integrated.
Q: What is CSRF protection and does Survanta use it?
CSRF can trick a cookie-authenticated browser into sending an unwanted state-changing request. Survanta uses controller-level automatic anti-forgery validation and explicit [ValidateAntiForgeryToken] on many MVC POST actions; API controllers that use bearer/API-key authentication explicitly ignore anti-forgery. Protection must be assessed per endpoint, not claimed for every form or request globally.
Q: Can someone access my survey responses without my permission?
Response access requires an authorized tenant permission, a valid read-only ResponseViewer public token, or a valid integration key with the required scope and plan capability. Public Single Survey and Portal tokens collect responses but do not grant response viewing. RawResponsesRead should be granted only when individual response rows are required.
Q: How does Survanta handle passwords?
Application accounts use ASP.NET Core Identity password hashing rather than storing plaintext passwords. Website confirmation and password reset use OTP forms, not reset links. The mobile Researcher surface can request and confirm a code but currently exposes no endpoint to set the new password; do not present that partial flow as complete.
Q: Is data in transit encrypted?
The web pipeline enables HTTPS redirection and HSTS outside development, and honors configured forwarded-proxy headers. End-to-end TLS still depends on correct deployment, reverse-proxy, certificate, and client configuration. Production clients should use only HTTPS URLs; source middleware alone cannot prove every deployed hop is encrypted.