Security and trust

Accounts are created against a verified e-mail address with a password. There are no shared logins, no default accounts and no demo workspace with real content in it.

• Accounts are created against a verified e-mail address with a password
• No shared or generic accounts — access is always attributable to a person
• The last owner of a workspace cannot be removed, so a workspace can never be orphaned

A workspace has four roles. The check happens in the API and in the database, not in the interface, so a modified client cannot talk its way past it.

• Owner — billing, members, domains and everything below
• Admin — members, domains, projects, publishing
• Editor — create and publish tours, no access to billing or members
• Viewer — read-only access to projects and analytics
• Role checks run server-side on every write, and only an Owner can promote someone to Owner

Every workspace table has row-level security enabled. A query that does not carry the right organisation context returns no rows — not filtered rows, no rows.

• RLS is enabled on all twelve workspace tables, including projects, tours, scenes, hotspots, assets and leads
• Cross-workspace reads are impossible at the database level, not merely blocked in application code
• Service-role access exists only inside the server, for the handful of operations that need it (audit writes, rate-limit bookkeeping)

Every response from the marketing site and the studio carries HSTS, a content security policy, and the standard anti-sniffing and framing headers.

• TLS on every page, API call and embed
• HSTS, CSP, X-Content-Type-Options, Referrer-Policy and Permissions-Policy on every response
• The viewer and embed routes are served with no-store, so a tour is not cached on a shared machine

A tour protected by a password stores a scrypt hash. The comparison is constant-time, so the response does not leak how much of the password was correct.

• scrypt hashing with a per-tour salt
• Timing-safe comparison on every attempt
• The unlock cookie is httpOnly, Secure and SameSite=Lax, and expires after 24 hours
• Five attempts per minute per IP; the sixth is refused with a Retry-After header

Analytics store the visitor's network rather than the address itself. A full IP is never written to the database.

• IP addresses are truncated to the /16 network before they are stored
• The truncated value is used for unique-visitor counting and nothing else

The build a visitor is looking at cannot change underneath them. Changes ship as a new version, and any previous version can be restored.

• A published version is frozen — the same build serves every visitor
• Full version history with one-click rollback
• Visibility is explicit: public, unlisted or password-protected

Beyond the password, a tour can be given an expiry date or restricted to a set of domains that are allowed to embed it.

• Expiring share links — the tour stops resolving on the date you set
• Domain allow-lists — the embed is refused on any host that is not on the list
• Both are enforced on the viewer and on the embed, not only in the editor

A tour can be exported at any time as a package containing the configuration and the source panoramas, so leaving Mango360 does not mean losing your work.

• Per-tour export: scene graph, hotspots, floor plans and branding as JSON, plus the source panorama files
• Analytics and lead data export to CSV
• Exports are produced on demand, with no lock-in window

Each write path has its own budget, keyed by IP address, and answers with the standard rate-limit headers so a well-behaved client can back off correctly.

• Ten publishes per minute, twenty unpublishes per minute, twenty rollbacks per minute
• Sixty analytics events per minute, thirty panorama processing jobs per minute
• Five lead submissions per ten minutes — the tightest budget in the system
• Responses carry X-RateLimit-Limit, X-RateLimit-Remaining and Retry-After

Publishing is the most expensive thing a client can ask the platform to do, so it carries the tightest write budget and the most validation.

• Every publish is a new immutable version with a full audit entry
• Version history records who published, when, and which version

The studio application reports errors and performance traces to Sentry, including session replay, so a fault is noticed before a customer reports it.

• Client error reporting and performance tracing in the studio application
• Session replay for reproducing a fault without asking the user to describe it

Administrative actions are recorded with the actor and the timestamp. This is a record for investigation, not a screen in the interface — if you need a per-action report, ask us and we will pull it from the database.

• Recorded: publishes, unpublishes, tour and project deletions, domain creations and verifications, live-session starts and ends, lead status changes
• Each entry stores the acting user, the action, the target and the time
• Sign-ins and membership changes are not recorded yet

The privacy policy and the terms of service are public and versioned, and each has a mailbox attached to it that a person reads.

• Privacy policy and terms of service, published on this site
• privacy@mango360.app for data-protection requests
• legal@mango360.app for contracts and agreements
• support@mango360.app for product questions

Requests to access, correct or delete personal data are handled by e-mail. We answer the ones that concern visitor data directly and forward the ones that concern your account data to the workspace owner.

• Access, correction and deletion requests at privacy@mango360.app
• We will confirm what we hold for a given visitor before acting on it

The list of service providers we rely on is available on request, as is a data processing agreement. Neither is a self-serve download today, and we would rather say so than pretend otherwise.

• The current subprocessor list is sent on request
• A data processing agreement is available for Business and Enterprise customers