Security
Norvis holds your project records and, for many of you, your financial ones. This page describes only what is enforced in the system today. Where something is not built yet, it says so.
Separation is enforced in the database, below our own code
Every record carries its organisation, and row-level rules in Postgres refuse to return another organisation’s rows whatever the application asks for. The separation sits one layer under our own features: a bug in a page runs into a second fence it cannot cross. A browser session holds no direct write access to the database at all. Every write passes through a signed-in server route, and the route takes your organisation from your session, never from anything the request claims about itself. We attack this separation with adversarial scripts run against the live product from real accounts in different organisations, and the written protocol that governs this codebase requires those sweeps rather than suggesting them.
Least privilege, checked on every request
Access is role-based, with twenty-three roles from a field crew to a reviewer, and every server route checks the caller’s permission before it acts. The grants are deliberately narrow: a site engineer’s role carries no financial permission of any kind, so financial figures are not theirs to fetch. An organisation’s admin can tune what each role may do, and role changes are themselves recorded.
A second factor
Any user can add a second factor: a time-based code from an authenticator app. Once it is enrolled it is not optional in practice, because a session that has only presented a password is stopped at the door and cannot reach any page of the app until the code is entered.
A record that only grows
Significant actions, who moved a date, who approved an invoice, who changed a role, are written to a record that the database accepts inserts into and nothing else: no rule for updating a row exists, and none for deleting one. Corrections are new entries. When you need to know what happened and when, the answer was written at the time and has not been touched since.
Issued documents freeze
An issued invoice takes its number from a gapless series for your organisation and financial year, and at that moment the document freezes. The refusal to change it is a database trigger, which means it binds every path in, including our own administrative credentials. Corrections happen through a credit note that carries its own number and names the original. Site photographs get similar treatment: each is fingerprinted with a cryptographic hash of the stored bytes when it arrives, stamped with the server’s clock and the GPS position of the shot, and has no edit path afterwards.
In transit
All traffic runs over HTTPS. Strict transport security is set for two years and preloaded, so a browser that has seen the site once refuses to connect any other way. A content security policy restricts where the pages may load code from, and the app cannot be embedded in another site’s frame. Sign-in itself is handled by our authentication provider; your password is not stored by our application.
Payments never touch us
Card and UPI details go to Razorpay, a regulated payment processor, and are never seen or stored by Norvis. Every billing message Razorpay sends us is checked against its cryptographic signature, in constant time, before we act on it. A forged “payment succeeded” message does not grant anyone a plan.
The API surface
API keys are stored only as hashes, so a copy of our database does not contain a single working key. Each key carries read or write scope and its own rate limit. Webhook deliveries we send are signed with HMAC-SHA256 so the receiving system can tell ours from a forgery. The public client portal works on revocable tokens, is rate-limited, and answers an invalid, expired or revoked link identically, so a probe learns nothing about what exists.
Where it runs
The application is served from the Mumbai region. If you have a specific data-residency requirement, ask us before you sign up and we will tell you exactly where your data sits.
Found something? Tell us
If you believe you have found a vulnerability, write to support@norvis.in, the address at the foot of this site, and put the word security in the subject. It reaches the people who build Norvis and we will come back to you quickly. There is no separate security-only mailbox yet: we would rather point you at one that is read than print one that is not. The contact page reaches the same people if you prefer a form. We would much rather hear it from you than not hear it at all.
We are a young company and honest about it: we hold no SOC 2 or ISO 27001 attestation yet, and we will not print a badge we have not earned. What we can do today is walk any prospective customer through exactly how the system is built, and we are glad to.