Security

weave is multi-tenant: many companies share the platform, and each company’s data is scoped to it on the server, from the signed-in session. The browser never chooses which company’s data it receives, so one customer cannot request another’s records by changing a request.

• Every API request is authorised on the server against the user’s role. Hiding a screen in the interface is never the control.
• Managers and department heads are scoped to their own teams and departments.

• Passwords are stored only as argon2 hashes, never in readable form.
• Single sign-on with Google is available where a workspace enables it.
• Sessions use short-lived access tokens with rotating refresh tokens, held in httpOnly cookies that page scripts cannot read.
• Idle sessions warn before they expire, and signing out clears them.
• On mobile, tokens are kept in the device’s secure storage.

Sign-ins, permission denials, approvals and changes to important records are written to an append-only audit log, so the history of who did what cannot be edited after the fact. Administrators can review it in the product.

• All traffic is served over HTTPS, with HTTP Strict Transport Security.
• Security headers block framing by other sites, MIME sniffing and unneeded browser features.
• weave undergoes independent white-box security assessments against the OWASP Top 10, OWASP API Security Top 10 and ASVS, and findings are tracked to resolution.
• Accessibility is assessed against WCAG in the same programme, because a secure product has to be usable by everyone.

If we become aware of a breach affecting customer data, we will contain it, investigate, and notify affected customers without undue delay with the information they need to meet their own obligations. See our Privacy Policy.

We welcome reports from security researchers. If you believe you have found a vulnerability in weave, email contact@emor.tech with:

• a description of the issue and its potential impact;
• the steps, URLs or requests needed to reproduce it; and
• how you would like to be credited, if at all.

Please

• test only against accounts you own or have permission to use, and never access, change or delete other people’s data;
• stop and report as soon as you can show the issue;
• give us reasonable time to fix it before sharing details publicly.

Out of scope

• denial-of-service or load testing;
• social engineering, phishing or physical attacks against our staff or customers;
• spam, and reports from automated scanners without a demonstrated impact.

We will acknowledge your report, keep you updated while we work on it, and not pursue legal action against research carried out in good faith under this policy. Our contact details are also published in security.txt.