Security
You are considering putting your business's public face, and your team's files, on somebody else's computer. Here is exactly what protects them, and at the bottom, what does not exist yet.
Your company's data cannot be reached from another company's account
This is the one that matters most, so it is worth being specific. Every piece of data (every file, website and record) is stored under a key that begins with your company's identifier. That identifier is read from the token issued when you signed in. It is never read from the request, so there is nothing in a URL or a form for someone to change in order to ask for another company's data.
Because that is a claim rather than a promise, it is tested. A suite that signs in as two separate companies and attempts to reach the other's data through every endpoint must pass before anything is released. A cross-company read is a failed release, not a bug report.
Passwords
Sign-in is handled by Amazon Cognito. Your password is set, stored and verified there. It never passes through our own code and we cannot read it. Resetting a password sends a code to your email rather than a link that stays valid.
What happens to a file you upload
Uploads go straight from your browser to storage using a link that we generate, that is valid for one hour, and that will not accept a file over 100 MB. The name and location of the stored file are decided by us from your account, not taken from the file you sent, so a crafted filename cannot write anywhere it should not.
Links you send to someone outside your company stop working after at most seven days, and we store only a fingerprint of the link rather than the link itself. Deleting a file keeps earlier copies for 90 days, so an overwrite is recoverable.
What we check before a website goes live
Two checks run on every upload, and each one can stop the publish.
- Credentials left in the code. Passwords and API keys are routinely pasted into a project and forgotten. We scan for them, and if we find one the site is not published. You are told what was found and where, so you can remove it and upload again.
- Code that could not have worked. Some mistakes mean the website would never have answered a single visitor. We would rather tell you which line to change than publish something that returns an error page to your customers.
Compressed files are also opened with limits on how many files and how much data they may expand to, so a malicious archive cannot exhaust the machine that opens it.
Websites that run their own program
On the paid plan your website can run code. That code runs in its own isolated function with no permissions to our cloud account at all. It cannot read another customer's data, our storage, or our configuration, because it holds no credentials that would let it. It is capped at 512 MB of memory and 20 seconds per request.
Your website's own data is reached with a key that is held on the server side and never sent to a visitor's browser.
Where your data is
On Amazon Web Services in the Singapore region, the nearest region to Malaysian visitors. Storage and database contents are encrypted at rest by AWS. We do not copy your data to other regions and we do not sell or share it.
What is not built yet
A security page that lists only strengths is a marketing page. These are the real gaps as of today.
- No formal certification. We hold no ISO or SOC audit. What we have is the design above and the test suite that enforces it.
- Your own domain name is paid-plan only. A free website is served at an address ending in ostiara.com. A paid website can use one address you already own, and one only.
- No published uptime figure. We do not yet measure availability over a long enough period to quote a number honestly, so we do not quote one.
- Payments are not switched on. No card details exist in our systems because none have ever been collected.
If you have a question this page does not answer, ask it. support@ostiara.com reaches the person who built the thing you are asking about. The privacy policy covers what we collect and why.