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 stored in an httpOnly session cookie with no stored expiry: the session ends when you sign out, close the browser, after 2 hours without activity, or at most 12 hours after sign-in. 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 subscription ends, the server serves only what the rules allow — administrators can view and download the data for a limited time, and nothing else. 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).

Three levels of isolation

Every customer's data is kept apart from every other customer's. The levels below build on one another, and the plan you choose decides how far you go.

All traffic is served over HTTPS (TLS).

What this protects against — and what it does not

Data is decrypted only in the memory of the system, while it handles a request from your own users. That single fact decides the answers below.

Your data

• You own your production data. We process it only to provide the service.
• Trial data. A trial is a normal organisation with its own encryption key. If the trial ends without a subscription, administrators can still view and download the data, and the organisation is deleted automatically 7 days after the trial ends — we email before that happens.
• Export at any time. Data goes in and comes out as Excel; you are never locked in by file format.
• Deletion. An administrator can request deletion of the organisation in the application, or by email from the registered address of an active administrator; it is carried out 24 hours after confirmation and can be cancelled until then. After a subscription ends, data is deleted automatically 30 days after the account is suspended. As soon as an organisation is deleted its data can no longer be read, and within 7 days it is unreadable in every backup.
• 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 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.