Security

Last updated 17 August 2026

How accounts and data are protected, stated specifically enough to be checked — and the gaps, stated too. If you have found a flaw, skip to reporting.

Card payments

Card details never reach our servers. Payment is handled entirely by Stripe: either on Stripe's own page, or in a Stripe-hosted iframe embedded in ours. The card number is typed into Stripe's form, on Stripe's origin, and our code cannot read it. We store only what a purchase was — amount, currency, tree count and Stripe's reference.

This is a deliberate architectural choice rather than a convenience: it keeps card data out of our systems entirely, so a compromise of our infrastructure could not expose a card number that was never there. Stripe is a PCI DSS Level 1 service provider; that is Stripe's certification, not ours, and we make no PCI claim of our own.

Accounts

• Passwords are stored as salted scrypt hashes with a per-user random salt — a deliberately slow, memory-hard function, so a stolen database is expensive to attack. Comparison is constant-time, so it cannot be used as a timing oracle.
• Session cookies are HttpOnly (page scripts cannot read them),SameSite=Lax (not sent on cross-site requests, which blocks the common CSRF shape), and Secure in production. The cookie holds a 256-bit random token and nothing else.
• Changing your password immediately invalidates every other session. That is the whole point of changing a password you think someone else has, and it is easy to build software that gets it wrong.

Your connected channels

• Every permission we request is read-only. There is no publish, post, message or delete scope in any of the four platform integrations. We could not post as you if we wanted to.
• You can revoke our access from the platform's own settings at any time, without involving us.
• Every database query is scoped to the account making it. A request that names another account's record finds nothing, because the account identifier comes from your session — never from the URL or a form field.

Uploads

Profile photos are accepted as PNG, JPEG or WebP only, and the type is determined by inspecting the file's actual leading bytes rather than trusting its extension or declared type. SVG is refused outright: an SVG can carry script, and one served from our own origin would run with our privileges.

What we do not yet do

This is an early-stage product and it would be dishonest to imply otherwise.

• Platform access tokens are stored unencrypted at rest. They are protected by the database's own access controls and by the provider's disk encryption, but not separately encrypted by us. Application-level encryption with a managed key is the right answer and is not built yet.
• No independent penetration test and no external security audit have been carried out.
• No two-factor authentication on GreenReach accounts yet. Use a unique password; a password manager is the practical way to.
• No formal certifications. See below.

Certifications

None, currently. GreenReach does not hold ISO 27001, SOC 2, Cyber Essentials or any equivalent, and does not display badges for them. Those are audited credentials; claiming one without the audit would be a false statement, and a security page that overstates itself is worse than one that admits a gap. If you are evaluating us and need a specific assurance, ask — we would rather answer a questionnaire honestly than point at a badge.

Note also what “GDPR compliant” does and does not mean: the GDPR has no certification scheme of the kind vendors often imply. What we can say is what we actually do with data, and that is set out in the privacy notice.

Reporting a vulnerability

If you have found a security problem, please tell us. Email billing@greenreach.app with enough detail to reproduce it. You do not need permission to report, and we will not pursue anyone who reports something in good faith.

What we ask:

• Give us a reasonable chance to fix it before telling anyone else — 90 days is the norm and we will usually be much faster.
• Use only accounts you own for testing. Do not access, modify or delete another customer's data; if you come across some by accident, stop and tell us what you saw so we can assess the exposure.
• No denial of service, no spam, no social engineering of our staff or customers, and no physical attacks.

What you get from us:

• An acknowledgement within three working days.
• An honest assessment, and a timeline once we have one.
• Credit when it is fixed, if you want it. We do not run a paid bounty programme and will say so rather than leave you guessing.