Don't use cgi::carp 'fatalstobrowser'; - in production code as it may show things you don't want people to see.
Double-check all user entered data and then don't trust it. Do you really need to let them enter a filename? (taint will catch most mistakes, but it's no infalliable).
Hardcode important settings. Using stuff like <input type="hidden" name="destination" value="test@example.com"> is just asking for people to send spam through your system - with YOUR name on it!
Make sure the script, file and folder it is in has minimum priviledges to do its job. For the sake of your server, never ever ever run a script as root: nor allow it to be. Also, if you are writing files, ensure that they can't be executed or anything. Last thing you want is for someone to upload a file with the contents rm -rf * and then visit the URL of the file
The end user has no need to know how or where your files are stored (it's a possible security loophole): having URLs like ?readfile=/usr/myuser/htdocs/files/0102.txt allows them to know where your files are. I'm saying nothing about them being able to alter the query string and read any file they want on your server... (something like ?readfile=0102 would be a lot more secure).
use cgi - it's tried, tested and quite secure. Rolling your own form parsing system may allow buglets to slip by... (use CGI or die;)
Be careful what error messages you do display to the user. Bad password will allow them to know that they've hit a correct username, Bad username or password doesn't allow them to know quite what went wrong. Lock out (or introduce a time delay) on accounts that have more than X invalid login attempts in a time period.
There's a lot of work you can do to make sure a system is secure (physical access, open telnet ports, default passwords etc etc are all potential problems and security holes), but the above should give you some assistance.