Before using scripts, you should be aware of our script policies. These restrict how much of the server's resources you may use, for example. By installing and using scripts, you're agreeing to these policies.
On this page:
If you plan to install scripts, you should have the ability to troubleshoot the software you install, or have access to someone who does (such as the author of the script).
Because scripts can be complicated, and we don't know how your script is supposed to work, we can't provide free support for scripts unless your question or problem seems to be unique to our servers.
For obvious reasons, you may not create any scripts that attempt to perform destructive, insecure, malicious or illegal actions (this is covered by our general Terms of Service). For example, you may not create a script that attempts to make another Web site crash by making repeated requests to another server.
We will also disable any script that unintentionally does something destructive or insecure — for example, if your script tries to run hundreds of copies of itself due to a bug, or if it creates a security risk as discussed below. (Of course, we would notify you right away if we disabled your script for this reason.)
Because a server must be able to support the sites of multiple customers, we have to set limits on what a Web site can use. This makes sure that one site doesn't use up all the available resources of a server and cause problems for others. Here are our "resource limit" policies:
You may use scripts to send a small quantity of e-mail messages to you — for example, sending the results of feedback forms.
(Please do not install your own version of the feedback script named "FormMail" from "Matt's Script Archive", as it has a number of issues that may allow others to use it to send spam. We provide a preinstalled secure version of FormMail for you to use instead.)
You may not use a script to send e-mail to other people without our prior permission. Using such scripts without permission is considered a violation of our anti-spam policy. See the sending e-mail from scripts page to learn how to get permission to use scripts to send e-mail.
You are responsible for the security of your own scripts. You, or the author of the scripts you upload, should have an understanding of common security issues related to creating scripts to ensure you don't inadvertently create security problems. While a complete discussion of this topic is beyond the scope of this page, we will mention a few examples of things that script authors should be concerned about.
One common problem is the possibility of creating a bug that allows others to hijack your scripts to send spam or access other servers. For example, old versions of the widely used "FormMail" script from Matt's Script Archive had this problem: anyone visiting a Web page that used FormMail could cause the script to send mail to random recipients by altering the information passed from the Web page to the script. (The version of FormMail we supply does not have this bug.) If your script sends e-mail or accesses other servers, be sure that your script uses a hard-coded list of destinations, rather than accepting the information from the parameters passed in from the Web page.
Another possibility is that a determined attacker might be able to read the source code for your script due to a bug or configuration problem, either in your code or our server software. While the Apache Web server software tries to ensure this is impossible, past bugs in that software, for example, have allowed clever attackers ways to view the source code. If your source code contains passwords or other sensitive information, consider moving that information to a separate file in your home directory and having your script read that information when it starts.
You'll also want to keep in mind that our servers run the Linux operating system, which is designed to be a shared system in many respects. One consequence of this is that other users might be able to see the names of programs that you run, as well as the contents of the "command line" of those programs. Make sure that the name of your script and the command line of any other program you run do not reveal any private information.
A good place to begin learning more about these issues is by performing a Google search on the phrase script security.