Security Policy

We treat security as part of the work rather than a phase after it. That means designing for it, reviewing it, and saying so plainly when something goes wrong.

We would rather fix a problem quietly than announce that we fixed one — except where the law requires us to notify affected people, in which case we will.

These apply to https://erstian.com and Internbird as they operate today:

Encryption in transit

HTTPS with TLS on every route, with HTTP redirected to HTTPS and no mixed content. Traffic between your browser and our servers, and between our servers and our providers, is encrypted.

Password storage

Passwords are stored as one-way salted hashes, never as readable text. Our database holds a hash, not a password, so a copy of it does not reveal your password. Plaintext password storage is treated as a serious incident.

Authentication

Accounts are identified by a unique email address or username, and sessions are issued server-side rather than trusted from the client. Session values are generated to be unpredictable and expire.

Access control

Access to production systems and production data is restricted to people who need it for their work, protected by multi-factor authentication where the provider supports it, and limited to the minimum data each task requires.

Authorization checks

Access to a user's own data is checked on the server against who is asking. Hiding a control in the interface is never the protection — the check happens where the data is.

Input validation

Input is validated on the server before it is used or stored, and output is encoded on the way out, so that submitted content cannot be used to attack the page that displays it.

Infrastructure isolation

Hosting runs on a managed platform that provides network-level separation between tenants, so one customer's environment is not shared with another's.

Rate limiting

Requests to sensitive endpoints — sign-in, registration, and anything that sends a message or triggers work — are rate limited to reduce the impact of automated abuse.

Dependency management

Third-party code is kept to a small, deliberate set and its versions are tracked, so a known vulnerability in a dependency can be identified and updated.

Logging and monitoring

Server and application logs record errors and security-relevant events — including failed sign-in attempts — so that misuse can be investigated. Logs are not used to profile visitors.

Backups

Data and configuration are backed up on a schedule, and the value of a backup is verified by restoring from it rather than only by confirming the job ran.

Payments are handled by a third-party payment provider on infrastructure we do not operate.

• Card numbers, card expiry dates, CVVs, UPI PINs and net-banking credentials are entered on the payment provider's own hosted checkout page and are never received by or stored on our servers.
• Erstian does not hold, process or have access to card data. This is why we do not claim PCI DSS certification of our own — cardholder data is out of our systems by design.
• Payment pages are served over HTTPS, and we do not transmit or log payment credentials.
• What we retain is limited to what is needed to deliver an order and administer billing: the transaction reference, amount, date, status, the email address on the order, and the service purchased.
• Refunds are issued back through the same provider, to the original payment method.

Stated plainly, because a security page that lists only strengths is not useful to the person deciding whether to trust us with their data:

• We hold no formal security certifications. We do not have SOC 2, ISO 27001 or ISO 27017 certification, and we will not claim one until we do.
• We have not commissioned an independent penetration test. We would rather say so than imply a review that has not happened.
• We do not operate 24/7 security monitoring with a dedicated response team. At our size the people who build the system are the people who respond to it.
• We do not publish a formal uptime or security SLA. There is no commitment we have measured well enough to promise.

This section shortens as each item becomes true. If it is out of date when you read it, that is a fault — tell us.

Report anything you think is a vulnerability to [email protected], on https://erstian.com or on Internbird. If that mailbox is unmonitored, write to [email protected] instead and say plainly that it is a security report, so it reaches whoever handles them.

Please include:

• What you found, and the steps to reproduce it.
• Which URL or feature it affects.
• What an attacker could do with it.
• Whether anyone else knows, and whether it is already public.

You can also reach us through the contact channel on https://internbird.erstian.com/ if you would rather not email.

1. 01We acknowledge your report within 2 business days.
2. 02We confirm whether we believe it is valid, and tell you either way.
3. 03We keep you updated while we fix it, and we will credit you in the release notes unless you would rather we did not.
4. 04We tell you when the fix is live.

We will not pursue legal action against you for good-faith research that respects other people's data and the availability of the service.

Testing is welcome. Harm is not. Please avoid:

• Accessing data that is not yours, beyond the minimum needed to demonstrate the issue.
• Degrading the service, running denial-of-service tests, or sending mail to anyone other than us.
• Automated scanning of the live site or platform, beyond a single ordinary scan.
• Submitting applications or content on behalf of someone else.
• Disclosing the issue publicly before we have had a fair chance to fix it.

A good-faith report that stops when we ask is not an attack. We would rather talk than sue.

We aim to acknowledge a report within 2 business days, give an initial assessment within 10, and fix a genuine issue as fast as we responsibly can. Severity sets the order, not who shouted loudest.

If a report turns out not to be a vulnerability, we will say so and explain why rather than leaving you guessing.

Where an incident affects personal information, our Privacy Policy describes what we will do and who we are required to notify. We will tell affected users, not only the regulator, where the law allows us to.

We will update this page when our security posture changes, and revise the date at the top. If a change affects a commitment we have made to you, we will tell you directly.

Erstian — https://erstian.com

General and privacy: [email protected]

Billing and refunds: [email protected]

Security reports: [email protected]

Questions about this document can be sent to [email protected]. We read every message and aim to respond within 30 days.

If you have a billing or refund question, email [email protected] with the email address on your account and the order or transaction reference, and we will pick it up from there.

If you are in the EEA, the UK or Switzerland and are unhappy with how we have handled your data, you may also complain to your local supervisory authority.