I have a site where the main database is interacted with via python scripts located in public_html\cgi-bin\. To run commands, various JavaScript scripts, located in \public_html\scripts\, use jQuery to call the different python scripts.

I have some python scripts, such as one used to delete and add entries restricted to users logged in via .htaccess accounts. The CGI, and JavaScript scripts interacting with them, however, are also located in the same folders. Is this dangerous? Can clients somehow call my python CGI scripts with their own CGI variables, or run my JavaScript scripts to do that for them?

How can I keep these scripts safe, if so?


If a user's browser is able to call (send HTTP request to) your Python scripts (with or without AJAX), then assume that an authenticated user will be able to send custom HTTP requests, including whatever variables (parameters) they want.

Always assume that not only your users are able to see your JavaScript code, but they're also able to modify it, override it, or completely disable it.

Putting your HTML, JS, or Python files in the same folder (directory) isn't a problem. But I'd advise you to move your scripts that contains sensitive information (like your database credentials) above your public_html directory (your www root).

| improve this answer | |
  • Alright, that certainly answers my question. So are you saying, however, that they may even be able to view my python scripts' content/source? How are they able to do that?...and if it's so important that I keep things all in www, what's the point of having a cgi-bin in all of my site's subfolders? – Freesnöw May 8 '13 at 14:06
  • 1
    @Xan if your webserver is configured to execute the python scripts and return the result, instead of returning them as-is, then no, the users won't be able to see your sources. Unless of course there's some misconfiguration in the webserver, then your scripts may temporarily leak until you make a fix (seen happening before). About the www, I think Adnan meant that only the scripts that the user will run should be in cgi-bin, the rest (that the users must not run directly or even see) should be in a place that the webserver will not run them (or return them, in case of a misconfig). – mgibsonbr May 8 '13 at 14:18

As a rule of thumb, never trust user input, even if you're confident it'll only come from authenticated users. If any of your CGI scripts are internet-facing (i.e. can be executed as a direct consequence of your users requests, be them the jQuery ajax calls or regular page access), you should sanitize all input fields and check proper authentication and authorization before performing any sensitive action.


If your webserver is configured to automatically run scripts in the cgi-bin folder in response to a matching URL address, then all scripts inside that folder are susceptible from being called by users, in ways that you can not predict or control. If you have scripts that must not be called this way, then you should either store them somewhere else or configure your webserver not to execute them automatically (for instance, whitelisting the URLs that will directly match server resources).

(If in doubt whether a particular script is or is not exposed, just replace it with an innocuous one and try calling it via corresponding URL)

As for the other scripts (those that are intended to be called from outside), you still have the problems of not having control of who will call them, in which circumstances they will be called, and whether or not they will be called with the right parameters. You could try to whitelist IP addresses or check the HTTP referer, but those are not bulletproof. The JavaScript that calls them can always be modified by the client, and trivially so (for instance, modifying the live page using bookmaklets), thus there's no way to know the code that prepared those requests is untampered with - even if they run in your page context. And the user can always change the script parameters to arbitrary values, either by misusing your code or by using his own (or by directly altering the HTTP request, among other means).

For those reasons, to be really safe you should always perform a full validation of the request before executing it: use a CSRF token, authenticate the user making the request (using a secure session cookie for instance - but .htaccess auth should also work), check the user authorization both to perform that action and to use the provided parameters, and check all parameters for the correct types/syntax and valid values. That may sound a lot of work, but once you get used to these practices it quickly becomes second-nature (and since you're using Python, an additional tip: look for decorators if you don't know them alreay, it'll make a lot easier the task of applying many of the above measures across different functions/scripts).

| improve this answer | |
  • Thanks for the comments regarding sanitation. I've made sure that all query's are executed using parameters. From testing and what I've read online, it seems to be a fairly simple way to prevent most SQL injections. Please correct me if I'm wrong, however. :) – Freesnöw May 8 '13 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.