Vulnerability disclosure

4.1 Purpose

The security of Shopfloor Wizard matters to us. This vulnerability disclosure policy (VDP) describes how security researchers can investigate and report possible vulnerabilities responsibly. It is meant to provide a clear, coordinated and reasonably safe reporting route.

This policy is not a bug bounty programme. There is no claim to payment, bounty or any other consideration unless expressly agreed in writing beforehand.

4.2 Scope

Generally in scope:

• shopfloorwizard.com;
• shopfloorwizard.de;
• subdomains of these domains operated by us;
• the Shopfloor Wizard web application we provide and our own application code.

Out of scope are systems and services operated independently by third parties, in particular infrastructure or accounts of Vercel, Supabase and Lemon Squeezy, unless the vulnerability rests directly on a misconfiguration or integration under our control.

Vulnerabilities found in a third-party service should generally be reported to that third party. Please do not run tests against systems you have no permission from the respective operator for.

4.3 Authorised security research / safe harbour

If you conduct security research in good faith, exclusively for defensive purposes and fully in line with this policy, we regard these activities as authorised in so far as we are legally able to do so.

We will not deliberately take civil or criminal action against you for such policy-compliant research. Should a third party take legal steps over an activity that in our assessment complies with this policy, we can confirm on request that the research was permitted under our policy, in so far as we are legally able to do so.

This safe harbour cannot grant rights in third-party systems and does not bind third-party providers or authorities.

4.4 Permitted test methods

Reasonable, non-destructive tests limited to the minimum necessary to demonstrate a vulnerability are permitted. Where possible, use your own test accounts and your own test data.

As soon as you have demonstrated a vulnerability sufficiently, stop exploiting it and report it.

4.5 Activities that are not permitted

The following in particular are not permitted:

• denial-of-service or distributed denial-of-service attacks;
• tests that materially impair availability for other users;
• social engineering, phishing, vishing or physical attacks;
• credential stuffing or mass login attempts with other people’s credentials;
• installing malware, persistence mechanisms, backdoors or cryptomining;
• deleting, damaging or deliberately altering other people’s data;
• accessing more of other people’s data than is strictly necessary for a minimal demonstration;
• downloading, copying, storing or publishing larger amounts of other people’s data;
• extortion, threats or withholding a report in exchange for payment;
• tests against Vercel, Supabase, Lemon Squeezy or other third-party systems outside a configuration under our control;
• public disclosure before the coordinated disclosure process under section 4.9 has run its course.

If you access another user’s data by accident, stop the access immediately, do not alter the data and include only the minimum necessary information in your report.

4.6 Reporting a vulnerability

Please report security vulnerabilities to:

support@shopfloorwizard.com

A helpful report contains, as far as possible:

• the URL, function or component affected;
• the type of vulnerability and its possible impact;
• reproducible steps;
• a proof of concept, screenshots or request/response examples where necessary;
• a note on whether and which third-party data was unintentionally visible;
• suggestions for a fix, if you have any;
• a way to contact you if you are open to follow-up questions.

You may generally submit reports without giving your identity. Please do not send unnecessary personal data.

4.7 What you can expect from us

We aim for the following response targets:

• acknowledgement of receipt usually within 5 working days;
• initial triage and feedback on relevance usually within 10 working days;
• reasonable status information for confirmed significant vulnerabilities;
• prioritisation of the fix by risk, technical complexity and possible impact.

These times are targets, not guaranteed service levels. Critical security problems are handled with priority where possible.

4.8 Confidentiality and data protection in reports

We use the information submitted exclusively for security analysis, communication, remediation, documentation, legal defence and, where applicable, legally required notifications. Researchers’ contact details are not published without an objective reason.

If you would like public credit, please tell us the name or alias you want used. Publication only happens by agreement.

4.9 Coordinated disclosure

Please do not publish details of an unfixed vulnerability without prior agreement. As a rule we ask for a coordinated disclosure period of up to 90 days from our acknowledgement of receipt. Depending on severity, active exploitation or technical complexity, a shorter or longer period may make sense and can be agreed together.

We will not delay a report unreasonably in order to keep legitimate security research permanently secret.

4.10 No claim to payment

Unless expressly agreed otherwise in writing, reporting or investigating a vulnerability creates no claim to payment, reimbursement of expenses, employment, a contract or any other consideration.

4.11 security.txt

To make the security contact machine-readable, a file according to RFC 9116 is to be published at /.well-known/security.txt on the domains we operate. The file is to be kept up to date, in particular its mandatory Expires field.

4.12 Changes

We may amend this policy, in particular when the technical scope, the reporting routes or security requirements change. The version published at the time of the security research is the one that applies.

Last updated: 1 September 2026