Security

This page describes the security measures that are actually in place at Astrina.io today. It is deliberately specific, and it is deliberately incomplete: where we do not have something, we say so instead of implying otherwise. If a security control is not listed on this page, assume we do not have it.

Where your data is stored

Astrina runs on a single server hosted with OVH in the EU. The server is managed with the Hestia control panel, and the database (MariaDB/MySQL) runs on that same server. Cloudflare sits in front of it for DNS, CDN, TLS termination and WAF.

The full list of third parties that process data on our behalf is on the Subprocessors page. What we collect and how long we keep it is set out in the Privacy Policy and the Data Retention page.

Encryption in transit

All traffic to and from Astrina.io is served over TLS. Cloudflare is configured in Full (strict) mode, which means the connection between Cloudflare and our origin server is also encrypted and the origin certificate is validated. The origin certificate is issued by Let's Encrypt.

Passwords

Passwords are stored only as a hash, produced by PHP password_hash() using bcrypt (PASSWORD_DEFAULT), and checked with password_verify().
We never store your password in plaintext, and we never write it to a log. Nobody at Astrina can read your password or tell you what it is.
Email verification and password reset tokens are stored as a SHA-256 hash of the token, are single-use, and expire.
Where a password is checked against known breach lists, we use the Pwned Passwords k-anonymity method: only the first five characters of the password's SHA-1 hash are sent. The password itself never leaves the browser or our server.

There is no two-factor authentication on Astrina accounts. See "What we do not have yet" below.

Sessions and forms

The session cookie is named astrsess. It is set HttpOnly (JavaScript cannot read it), Secure (it is only sent over HTTPS) and SameSite=Lax.
State-changing form submissions carry a CSRF token, so another site cannot make your browser perform an action in your account.

API keys

Your API key is accepted only in a request header — X-Api-Key, or Authorization: Bearer. We deliberately do not accept keys in the URL query string.
That choice matters: a key placed in a URL tends to end up in server access logs, proxy logs, browser history and Referer headers sent to other sites. A key in a header does not.
You can regenerate your key at any time from /my/api.php. Regenerating revokes the old key instantly.
Each plan has a daily call quota. Once it is used up, the API returns HTTP 429 rather than continuing to serve requests.

Cross-origin access (CORS)

Our public API methods are intentionally open to any origin (Access-Control-Allow-Origin: *), because they serve public catalog data. The private analytics method, /api/v1/stats, sends no Allow-Origin header at all — so a web page on another site cannot use a visitor's browser to read your statistics, even if it somehow had your key.

SEO crawler hardening

Our SEO crawler fetches URLs that customers supply, which is exactly the kind of feature that gets abused to reach internal systems (SSRF). It is hardened against that:

Only http and https URLs are accepted.
Private, loopback and link-local IP ranges are refused.
The resolved IP address is pinned, so the hostname cannot resolve to something different between the check and the request.
Every redirect hop is re-validated against the same rules, not just the first URL.
The response body size is capped.

Session recording is masked by default

If you enable the optional session recorder, masking is on by default and is enforced in the visitor's browser — before anything is sent to us:

Password, email and telephone input fields never transmit a value at all. Not the text, not a masked version of it, not even its length.
Payment-card fields are treated the same way.
Text typed into any other input is masked to bullets.
Any part of your page you mark with the [data-astr-mask] attribute is redacted before it leaves the browser.

Recordings are kept for 30 days by default. The retention period is configurable.

Evidence files on reviews

Images and video attached as evidence to some review types are stored outside the web root, so they cannot be fetched by guessing a URL. They are served only through a gated endpoint, which returns 403 unless the review has been approved, or you are the author of the review, or you are an admin.

Abuse and bot controls

Review submissions are rate-limited per IP address, and reviews are moderated. Reviews from guests are published only after moderation; reviews from signed-in members publish immediately.
Analytics traffic is filtered for bots using user-agent rules together with datacenter and hosting IP classification via reverse DNS.

Admin access

The admin area is gated by a role check on the account. Administrative accounts use the same login mechanism as everyone else, which means they are also not protected by two-factor authentication.

Email we send

Outbound email (from noreply@astrina.io) is sent by our own Exim mail server with DKIM configured, so recipients can verify that a message genuinely came from us. We do not pass your address to a third-party mail provider.

Backups and restoring the service

Hestia takes one daily backup of files and the database, at approximately 05:12 UTC.

Backups are stored on the same server that runs the service. There is no off-site copy and no geo-redundant replication. This is a real limitation and you should factor it into your own planning: an event that destroys the server would also destroy the backups stored on it. In practice roughly one daily copy exists at any time.

If the service needs to be restored, we restore from the most recent daily backup. We do not guarantee a recovery time objective (RTO) or a recovery point objective (RPO), and we do not offer a public service level agreement. An SLA exists only where one has been separately agreed in an individual contract.

What we do not have yet

We would rather tell you this plainly than let a security page imply more than it should. Astrina does not currently have:

No two-factor authentication (2FA), and no SSO for the Astrina panel itself.
No third-party security audit and no penetration test. None has been performed, so there are no results to publish.
No ISO 27001, SOC 2 or any other certification. We are not certified or audited against any standard.
No off-site backup. See the backups section above.
No bug-bounty programme. We accept reports, but we cannot pay for them.
No formal service level agreement and no published uptime guarantee.

If any of these are a requirement for you, they are absent today, and you should decide accordingly.

Reporting a security problem

If you find a vulnerability, please report it to support@astrina.io. This is the only contact address for security reports.

It helps if you include the affected URL or endpoint, the steps to reproduce, and what an attacker could achieve. Please give us a reasonable opportunity to fix an issue before disclosing it publicly, and please do not access, modify or delete data belonging to other people while testing.

We do not run a bug-bounty programme and cannot offer payment or a reward for reports. We also do not promise a response time, because we do not offer a public SLA — but reports sent to this address do reach us and we do act on them.

Your data and your control over it

You can delete an individual tracked site from your panel at any time, which removes its data.
You can regenerate or revoke your API key at any time from /my/api.php.
There is no self-service account deletion button in the panel today. To have your account and data deleted, email support@astrina.io and we will do it on request.

Privacy Policy — what we collect and why
Data Retention — how long each kind of data is kept
Subprocessors — the third parties involved
Cookies — what is set, and on whose domain
Data Processing Agreement
Terms of Service · Acceptable Use Policy
Contact