WellSite by SMEPro support@smeprotech.com
WellSiteby SMEPro

Report a security issue

How to tell us about a vulnerability, what we will do about it, and our commitment not to come after you for finding it.

Last updated 7 August 2026
On this page
  1. What is in scope
  2. What is not
  3. Testing without causing a problem
  4. What to expect from us
  5. Safe harbour
  6. What we already do
  7. Contact
Found something? Write to security@smeprotech.com. You will get a human reply within two working days. We will not threaten you, we will not ask you to sign anything before we listen, and we will tell you when it is fixed.

What is in scope

Anything on wellsite.app, mobile.wellsite.app, ediefile.com, and the API under /api/ on either. That includes the workspace, the field application, the managers console and the public marketing site.

We are most interested in anything that lets one operator reach another operator's data, anything that gets past sign-in, anything that lets a customer act as an administrator, and anything that would let somebody take the operator directory in bulk. Those are the four that would actually hurt.

What is not

Reports from automated scanners with nothing behind them. Missing security headers with no demonstrated impact. Rate limiting on endpoints that do not need it. Social engineering of our staff or our customers. Anything requiring physical access to somebody's unlocked machine. Denial of service — please do not, it affects operators trying to file.

How to test without causing a problem

Use your own account and your own data. If you need an account to test with, ask and we will give you one. Do not access, modify or keep another operator's data — if you find you can, stop, and tell us what you did to get there.

Do not run load tests or scanners against production. Well operators are filing against deadlines on the other side of it.

What you can expect from us

WhenWhat happens
Within 2 working daysA reply from a person confirming we have it
Within 5 working daysOur assessment: whether we agree it is a problem, and how serious we think it is
ThenRegular updates until it is fixed, and a note when it ships

We do not currently run a paid bounty programme. We will credit you publicly if you would like that, and we will keep you anonymous if you would prefer that instead.

Safe harbour

If you follow the rules above, make a good faith effort to avoid harming customers or their data, and give us reasonable time to fix what you find before telling anybody else, we will treat your work as authorised. We will not pursue legal action against you and we will not ask anyone else to.

That commitment is not conditional on us agreeing the finding is serious.

What we already do

Everything travels over TLS. Passwords are salted and hashed. Every endpoint that touches customer data requires a live session, and cross-operator access is refused at the server rather than hidden in the interface. The managers console needs its own credential, separate from any customer login, and is restricted by role, so a sales login cannot reach an account, an invoice or a workspace.

Our deploy script asserts the security posture on every release: it fails the build if an endpoint that should require authentication starts answering without it, and it checks that nothing private has become publicly reachable. Durable data is backed up and the restore is tested rather than assumed.

Contact

Security reports: security@smeprotech.com
Privacy questions: privacy@smeprotech.com
Everything else: support@smeprotech.com

Why we bother writing this down. The alternative to a disclosure page is a researcher who finds something, cannot work out who to tell, and posts it instead. We would much rather hear it from you first. security@smeprotech.com