Security

The one principle

Every security decision in LineProTrack follows a single rule: the browser decides nothing that matters. Who you are, what you may see, which features you may use and whether your subscription is still active are all decided again by the server on every single request.

The practical consequence: a technically capable user can open developer tools, edit the JavaScript, modify the downloaded HTML, or replay requests with Postman or curl — and still cannot grant themselves permissions, extend a trial, or read another company's data. Every one of those paths goes through the server, and the server re-checks everything.

This is not the norm. A large share of business software puts permission logic in the front end, where changing one line of JavaScript defeats it. LineProTrack does not.

Authentication and access

• Two-token sessions. Signing in issues a short-lived access token (JWT, 15 minutes) sent with each request, and a refresh token valid for 7 days stored in an httpOnly cookie. Page JavaScript cannot read that cookie, so even a cross-site scripting flaw would not hand an attacker a usable session.
• Passwords are never stored in readable form. They are hashed with scrypt using a unique random salt per user. A system administrator with full access to the data files cannot read them.
• Constant-time comparison. Password verification uses crypto.timingSafeEqual, which prevents timing attacks — measuring response times to recover a secret character by character.
• Four roles. viewer (read only), operator (data entry), planner (scheduling), admin. Every API endpoint enforces a minimum role itself; it does not rely on the interface hiding a button.
• Brute-force limits. Sign-in attempts are rate limited per network, and the API as a whole is rate limited.
• Subscription state is enforced server-side. When a trial or licence expires the API returns an error and no data is served. There is no client-side flag that can switch the check off, and the user's system clock is irrelevant.

Customer data isolation

Where several companies share one installation, isolation is the control that matters most. Two design decisions carry it:

• The tenant identifier is always taken from the server-signed token — never from anything the browser sends in a URL, body or header. Trusting a client-supplied tenant id is the single most common cause of cross-customer data leaks in SaaS products; the code is written so that it cannot happen here.
• Computation caches live inside a single request and are never shared between customers, so one company can never be served a result computed for another.
• Data file names are validated against a strict pattern, blocking path-traversal attempts, and uploaded content is screened for __proto__ / constructor / prototype keys to prevent prototype pollution.

Browser-side hardening

• Strict Content Security Policy. The browser is instructed to execute only the exact script blocks the server has signed with a SHA-256 hash, and to refuse every inline event handler (onclick=, onerror=) regardless of how it got onto the page. This is the last line of defence: even if malicious content were somehow injected, the browser would refuse to run it.
• No inline handlers anywhere. All interactive elements go through a central dispatcher with a whitelist of permitted actions. Parameters travel as JSON data and are never interpreted as code.
• Standard hardening headers are enabled: HSTS, X-Content-Type-Options, frame-ancestor restrictions and a strict referrer policy.

Protecting the scheduling engine

The forecasting and recovery-plan logic — the part built on two decades of factory scheduling experience — exists only on the server and is never sent to a browser. The browser submits raw data; the server computes; a filtering layer then returns only the conclusions (which line runs which day, whether the order lands on time, whether overtime is needed) and never the underlying parameters.

An automated check runs on every API response in non-production environments and blocks the response outright if internal fields ever leak into it — a loud failure is preferable to a silent one.

Supply chain and dependencies

• No third-party CDN. Every library, font and icon is served from our own infrastructure. A compromised public CDN cannot inject code into LineProTrack — and as a side effect, the product works normally behind corporate and national firewalls that block external CDNs.
• No advertising, analytics or tracking scripts run in the application.
• Dependencies are pinned and reviewed; known-vulnerable versions are replaced (for example, the spreadsheet library was upgraded to a release that fixes CVE-2023-30533).

Deployment options

For the hosted service, all traffic is served over HTTPS (TLS). For on-premise deployments, transport security is configured within your own infrastructure and we provide the recommended configuration.

Your data

• You own your production data. We process it only to provide the service.
• Trial data. If you send us a schedule to set up a trial, it stays inside that trial instance. When the trial ends you either continue with the same data or we delete the instance — your choice, and we ask before doing either.
• Export at any time. Data goes in and comes out as Excel; you are never locked in by file format.
• Deletion. On written request we delete your instance and its data within [[deletion window — to be confirmed, e.g. 30 days]], backups included.
• Details of personal data handling are in our Privacy Policy and Data Processing Agreement.

Current status and roadmap

We would rather tell you where we are than imply a maturity we have not reached. The architecture above is implemented and in use today. The following are not in place yet, and we will say so in a security review rather than let you discover it later:

If your procurement process requires any of these, tell us early. We will answer honestly about what exists, what is planned, and what we will commit to contractually.

Reporting a vulnerability

If you believe you have found a security issue, please email lineprotrack@gmail.com with enough detail to reproduce it. We aim to acknowledge within [[response time — to be confirmed, e.g. 3 business days]] and will keep you informed until it is resolved. Please do not test against other customers' data or run denial-of-service tests against the hosted service.

We do not currently operate a paid bug bounty programme, and we will not take legal action against researchers who report issues in good faith and give us reasonable time to fix them.

Questions about this document? Write to lineprotrack@gmail.com.