Security

Courses, uploads, and generated content are tied to the workspace they were created in. Users only access the workspace their account is assigned to — content in one workspace is not visible to, or accessible by, users in another.

Workspace administrators can view all content within their own workspace. No cross-workspace access is available to standard users. File paths, exports, and signed delivery links are all scoped to the originating workspace.

All Studio areas — editor, library, workspace management — require a valid authenticated login. Credentials are issued per user and cannot be used to access other workspaces.

Passwords are stored using bcrypt hashing. Plain-text passwords are never stored or logged. Access control and permission boundaries are enforced server-side on every request.

Sessions are subject to an inactivity timeout. When a user resets their password, all existing sessions for that account are immediately invalidated — any other browser holding an active session is signed out automatically.

Login and password reset endpoints are rate-limited by IP address to prevent brute-force and credential-stuffing attacks.

All Studio traffic is served over HTTPS. In production, HTTP Strict Transport Security (HSTS) is enforced, instructing browsers not to connect over plain HTTP for up to one year.

The following HTTP security headers are applied to every response:

• Content-Security-Policy — restricts which scripts, styles, and external resources the browser may load
• X-Frame-Options — prevents the Studio from being embedded in external iframes (clickjacking protection)
• X-Content-Type-Options — stops browsers from MIME-sniffing responses away from their declared content type
• Referrer-Policy — limits the referrer information sent to third parties
• Permissions-Policy — disables browser access to camera, microphone, and geolocation

All forms and authenticated requests are protected with CSRF tokens, preventing cross-site request forgery attacks.

Session cookies are issued with the following flags in all environments:

• HttpOnly — the session cookie is not accessible to JavaScript, mitigating XSS-based session theft
• SameSite=Lax — the cookie is not sent on cross-site POST requests, providing an additional layer of CSRF protection
• Secure — in production, the cookie is only transmitted over HTTPS connections

Sessions expire after a configurable period of inactivity. Resetting a password invalidates all other active sessions for the account immediately.

The platform accepts .docx, .pdf, and .pptx source documents. Uploads are validated at two levels:

• Extension check — filenames with disallowed extensions are rejected before the file is read
• Magic-byte verification — the actual file content is inspected to confirm it matches the declared type; a renamed executable will not pass validation even if its extension is correct

Upload size is enforced server-side. Upload attempts that fail content validation are recorded in the audit log. Uploaded files are stored within the workspace and are not publicly accessible. Hosted course delivery uses signed, authenticated links rather than direct file paths.

When a course is complete, a hosted preview URL is generated. This link is intentionally shared — only someone with the specific URL can access the hosted course. Courses are not indexed in public search engines or listed in any public directory.

You control when and with whom the link is shared. If a course is deleted from the library, its hosted preview link becomes inactive. Export links can optionally be signed with a configurable expiry to prevent indefinite access.

Security-relevant events are recorded to an append-only audit log, including:

• Login and logout activity
• Failed login attempts
• Password resets and credential changes
• User invitations and account changes
• Course creation, export, and archival
• Upload rejections (including content validation failures)
• IP-based access blocks

Each log entry includes a timestamp, action, outcome, user identity, role, and client IP address. Logs are accessible to platform administrators and are used to support security review and incident investigation.

Workspace separation, controlled access, and intentional sharing are central to how Mimr Studio is built. Uploaded content and generated outputs remain within your workspace and are not used to train AI models, not shared beyond the workspace they belong to, and processed solely for course generation and editing workflows.

Mimr Studio is available both as a cloud-hosted service and as a self-hosted deployment (via Docker). Self-hosted deployments run entirely within your own infrastructure — no data leaves your environment. For cloud deployments, all data is encrypted in transit and at rest on our hosted infrastructure.

For specific questions about data handling, workspace security, or enterprise requirements, contact us at security@mimrstudio.com.