Some of these posts aren't entirely accurate. Your script need not be executable by "everyone", so long as it's executable and readable by the web server. A few common setups:

• Web server running as 'nobody', CGI scripts owned by you, 'user' in an inconsequential group. A good set of permissions: 755.
• Web server running as 'nobody', CGI scripts owned by you and other members of a 'webdocs' group. Your umask is probably set up 002 and the directories are g+s. A good set of permissions for your scripts: 775 (permitting others in the 'webdocs' group to modify them, but still nobody else).
• Web server running as 'webuser' in the 'webuser' group. CGI scripts owned by you in an inconsequential group. A good set of permissions: 755, or even better: chgrp 'webuser' and 750 (only group 'webuser' needs to read them). This is more secure than above examples, because only you and those that need to see the script can read/execute it. Of course, if somebody exploits a poorly written script elsewhere, it's possible he can still get at the contents.
• Web server running as 'webuser' in the 'webuser' group. CGI scripts owned by you and a 'webdocs' group. A good set of permissions: 775. This is how many corporate environments are set up (see umask and other information above for how the directories are set up), so that a group can maintain documents, but we don't get as much out of running the server as a real user (versus 'nobody'), since everything has to be world-readable anyways.
• Web server running as 'webuser' in the 'webuser' group. CGI scripts owned by a 'webdocs' user and the 'webuser' group. All modifications are done through a role account, ensuring homogenous ownership. A good set of permissions: 750. The 'webuser' group can read/execute, so the web server can get at it, but the world can't do squat, so it's reasonably secure outside of your circle of webuser group and the webdocs account.

Note that all of these examples never once give the web server write privileges of your script. This is pretty important, and your web documents are the same. (Don't, for example, put the user the web server runs as in, say, the 'webdocs' group.) If your web server is broken into, or your scripts have a vulnerability allowing people to execute arbitrary code or commands, they'll only be doing this as the 'webuser' user, which means they can see and execute your other scripts, but cannot change them. Though in all practicality, with enough skill, this level of access is typically just a springboard to some other local system exploit giving them root access, but the vast majority of site break-ins don't go this far. Usually they're just out to deface a web page, in which case permissions like this would stop them.

If you did want to go a bit further as another poster suggests, you could further restrict 'production' code and web pages to the user the web server runs as, and set its permissions horribly restrictive (500 or 400 for web pages). Of course, doing this would allow a potential intruder to simply execute a chmod command and get full write privileges again. Even though it may look more secure, that sense of security is false.