Scan reports in HTML are downloaded in WebUI

[jess-tech-lab]

Summary

Currently, when using the WebUI, clicking the link for a completed scan result triggers an automatic download of the HTML file. While having the file locally is useful for archiving, it would improve the user experience if the report rendered directly in the browser.

Steps to Reproduce

In WebUI, click any scan result e.g. https://127.0.0.1:8080/results/get?id=2, the result in HTML is downloaded

I expected scan results in HTML are viewable in the browser window of WebUI

Suggested Fix

The API in nettacker/api/engine.py can change text/plain to text/html and attachment to inline at least for HTML files.

Nettacker/nettacker/api/engine.py

Lines 373 to 376 in ed9c8ca

	@app.route("/results/get", methods=["GET"])
	def get_result_content():
	"""
	get a result HTML/TEXT/JSON content

Nettacker/nettacker/api/engine.py

Lines 393 to 394 in ed9c8ca

	mimetype=mime_types().get(os.path.splitext(filename)[1], "text/plain"),
	headers={"Content-Disposition": "attachment;filename=" + filename.split("/")[-1]},

I am curious if the current "force download" behavior was a deliberate design choice to mitigate security risks, such as preventing potential Cross-Site Scripting (XSS). We might implement a secure rendering method like a sandboxed iframe or strict Content-Security-Policy headers to balance safety with a smoother UI.

I would love to contribute a fix for this if the maintainers agree this is a worthwhile improvement. Please let me know if you would like me to submit a PR.

[Sunuz-078]

Hi...!

I would like to work on this issue.

I will investigate the current Content-Disposition handling in the WebUI report endpoint and update it to allow inline HTML rendering while ensuring proper security headers are set to prevent XSS or unsafe content execution.

Please let me know if anyone is already working on it. Thank you!

[denma98]

Hey, is this still up for working upon?

[jess-tech-lab]

Hey, is this still up for working upon?

I've already started working on this. It proved to be a bit of a balancing act between security enhancements and supporting the page's rich JS/CSS, so it's taking a little more time than expected. I should have the PR ready for review by next week!

[Pbhacks]

Hi, I have tried to resolve this issue can you check my PR if it is appropriate

[jess-tech-lab]

Hi, I have tried to resolve this issue can you check my PR if it is appropriate

Hi @Pbhacks, thanks for the PR!

I have reviewed your changes and left a specific suggestion on the PR to further harden the report security.

I’ve suggested adding the sandbox allow-scripts directive to the Content-Security-Policy header. By using allow-scripts without allow-same-origin, we allow the D3.js and renderjson visualizations to function while forcing the report into a unique origin. This ensures that even if malicious data is present in the scan results, it cannot access site-wide cookies or local storage.

I also suggested adding a trailing ; to the font-src attribute to ensure the policy remains valid as we add these new directives. Looking forward to your thoughts on the PR!

[Pbhacks]

Hi @jess-tech-lab , I've checked your suggestions and added them. Thanks a lot for sharing your insights.