WizCountsReport a security problem
WizCounts keeps bookkeeping records, payroll and tax data for small Canadian businesses. If you have found a way to reach data or functions you should not be able to reach, we want to hear about it, and we would rather hear it from you than from a customer.
Where to send it
Our contact address is published in our security.txt file, which is the machine-readable record defined by RFC 9116:
That file names the address to write to, the date it stops being current, and — where one is published — a link back to this page.
The address lives in that one file rather than being repeated here so there is a single place to keep current. If the file is not reachable, this deployment has not published a disclosure address yet; in that case, contact the person or firm who set up your WizCounts account and ask them to pass the report to WizCart Technologies Inc.
What is useful in a report
- What you did, in enough detail that we can repeat it — the URL or screen, the steps, and the account type you used.
- What you saw that you should not have seen, described rather than pasted. Please do not send us copies of other people's data.
- Why you think it matters: what an attacker gets, and roughly how hard it would be.
- How you would like to be credited, if we publish anything about the fix, or if you would rather not be.
What we ask of you
This policy covers good-faith security research. That means testing that is intended to find and report a flaw, and that is kept as small as the finding requires:
- Use your own account and your own test data. Do not access, alter, download or keep anyone else's records — and if you reach someone else's data by accident, stop and tell us what happened.
- Do not degrade the service for other people: no load or denial-of-service testing, no spam, no mass scanning that amounts to the same thing.
- Do not test the people. Phishing, pretexting, or any other social engineering of our staff, our customers or their accountants is out of scope, as is physical access to anyone's premises or devices.
- Give us a reasonable chance to fix the problem before you tell anyone else about it.
Our side of it
We are a small team and we will not pretend to a support desk we do not have. What we will do:
- Read your report, and reply to tell you we have it.
- Tell you plainly whether we think it is a real problem, and what we intend to do about it.
- Let you know when it is fixed.
Two things we are not promising. We do not publish a guaranteed response time — a deadline we might miss is worth less to you than an honest reply. And we do not run a paid bug bounty; there is no reward schedule, and no payment should be expected or requested for a report.
Legal
If you follow this policy — good-faith research, within the limits above — we will treat your testing as authorised, and we will not initiate or support legal action against you over it. If someone else brings a claim about research that stayed inside this policy, we will say publicly that it was authorised.
That commitment reaches exactly as far as this policy does, and no further. It is not permission to access customer data, to keep what you find, to disrupt the service, or to test systems that are not ours. It also cannot bind third parties: our hosting provider, payment processor and other suppliers run their own systems under their own terms, and testing them is between you and them.
What is in scope
The WizCounts web application and its API on the domain you signed in to, this public site, and the security.txt file above. Findings from an automated scanner with no demonstrated impact, missing hardening headers with no path to exploit them, and best-practice reports without a concrete attack are not, on their own, vulnerabilities — send them if you like, but say what an attacker would actually be able to do.
Related
Our accessibility statement covers a different kind of report: pages or controls that are hard or impossible to use with a keyboard, a screen reader, or at a larger text size.