Many python files in www directory

Hi all,

I have implemented ERPNext and other Frappe-based applications many times, but it was the first time a Penetration Test and Vulnerability Assessment have been performed in one of our ERPNext instance. One of the medium-threat issue that was identified was that many python files are accessible via browser. For example, if I open <ERPNext_Hostname>/login.py, suddenly the lines of login.py file are exposed on the browser. According to the recommendation, we are supposed to eliminate that to prevent would-be-attackers from knowing the logic of our codes. My argument is that the logic is available publicly on GitHub anyway.

Upon checking the source code, I realised that those files that are accessible via web browser is placed under www folder. My real question is that why are they placed in this folder? I understand that the html files are also stored here and it is fine because they are meant to be publicly accessible, but the python files? If someone could shed some lights that would be awesome. If the python files are not needed here anyway, would it be possible to move them somewhere else?

Thank you and looking forward to hearing some responses from the brilliant minds here.

Cheers,
Hans

1 Like

The Python modules in the www folder are used as context generators for your Web Pages. You can write dynamically rendered pages with some logic written in your Python backend. Here’s the docs:

https://frappeframework.com/docs/v14/user/en/guides/portal-development/context


I don’t think the Python files should be accessible like {site}/login.py. I’ve raised a fix for the same:

1 Like

Hello Hans,

Can you elobarate a little bit more about the Penetration Test and Vulnerability Assessment? Did the client requested? What type of checks performed? How long did it take?

Hi TurkerTunali,

Yes it was a requirement by one of our clients and it was performed by a 3rd party (a vendor in Indonesia). I will be happy to provide a reference should you require one.

Basically the test methodology was using Penetration Testing Execution Standard approach, and it took several days to complete. The objective was at that time to find out if there are any vulnerabilities in ERPNext application.

Cheers,
Hans

1 Like