Upload Insecure Token HTTP Remediation

[lachlan-robinson]

Description
This PR requires: #37

• Upload remediation report for Insecure Token HTTP Vulnerability

Type of change

• Documentation (update or new)

[netlify]

✅ Deploy Preview for ontrackdocumentation ready!

Name	Link
🔨 Latest commit	e7e84c5
🔍 Latest deploy log	https://app.netlify.com/sites/ontrackdocumentation/deploys/6821a9b982e99600082c0105
😎 Deploy Preview	https://deploy-preview-38--ontrackdocumentation.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[ibi420]

Hello @lachlan-robinson, good work on identifying this false positive. Your documentation is in the correct .md format and is properly structured. Your documentation clearly explains the false positive and showcases why this vulnerability does not pose an issue in production. Thank you for the opportunity to review your work.

[samindiii]

Hi Lachlan!

Overall, your documentation is well-written, grammatically correct and is logically structured. Great job identifying that the security issue was a false positive but also outlining that these vulnerabilities are usually a security concern but not in dev environment.

[atharv02-git]

Hey @lachlan-robinson, just went through your work and here's my understanding:

1. Your documentation was really helpful and clearly guided me in understanding where the vulnerability lies and how it is mitigated in production. I believe your justification is valid the explanation you provided around proxy-nginx.conf enforcing HTTPS and protecting tokens makes complete sense.
2. To verify things on my end, I retested the login flow using the production flag. However, based on my current setup, I suspect it still uses the default nginx.conf (development configuration), not proxy-nginx.conf. Because of that, I was able to capture the authentication token in plain HTTP responses using Burp Suite.
   
3. Your explanation of how proxy-nginx.conf properly handles HTTPS and avoids this vulnerability aligns with best practices I just wasn’t able to fully test it due to my limited understanding of how to reroute Docker or Compose to use the reverse proxy setup instead of the default config.
4. If I manage to retest using proxy-nginx.conf, I expect your justification would hold up exactly as described.

Great work documenting this clearly it helped me understand the issue from both a configuration and security standpoint. LGTM! 🫡👌

[aNebula]

LGTM