The problem is, when you are just learning how to do stuff in web development you will make mistakes. You won't even know you made a mistake until it turns into a security hole and someone uses it to hack your site.
Below are a few things that you should know. The information is not too detailed, this is just a list to keep in mind. Using google you can easily find more information about each topic...
What others see from your code
While seeing errors during development is essential for a bug-free code, on a live site you should hide it from everyone but the admin user. Otherwise the user experience will suffer or sensitive information could get out into the wild.
Your website must never access the database server with the root user. If it does and a hacker acquires file access privileges, the whole database with multiple sites will be compromised. Create a separate user with a strong enough password for each website that can access only that particular database that it needs to operate on.
All input from users needs to be checked before database activity. If the input is not filtered, it can be used to execute SQL command on the database. This can be used to drop the complete database or to create further vulnerabilities like adding an another admin user.
Using mysql_real_escape_string() on all elements of the $_REQUEST and $_GET array is a simple solution for this problem.
Users are universally lazy and tend to use simple passwords that they can easily remember. They also tend to use the same password on multiple websites, which puts them at risk. You can either set secure random passwords to the users or guide them to create better ones with rules like requiring a capital, a smaller case and a number in the at least 8 character long password. Showing a password strenght meter might also convince some users to use better passwords.
Password protection in database
Storing passwords in the database using clear text is a really bad idea. Not only is it bad for the website, but also for all it's users as people tend to use the same password, username and email for multiple sites. Gaining access to a database with clear text passwords could provide access to all it's users personal data on other websites and services too.
The password itself must be thrown away and only a representation of it can be stored. This representation is a one-way encrypted, so called hashed version of the password. You could use algorythms like md5() or sha1() to hash the password and store the result in the user database.
Unfortunately this is not enough as so called rainbow tables built for the hashing algorythm can be used to decypher the passwords. To make such brute force attach harder to execute, salt can be used to modify the password before hashing to make the guessing much harder or even impossible using pre-calculated values. The best practice would be by using unique salt for each user when hashing as a public salt for all passwords could fall in the hackers hand.
$hash = md5($salt.$password);
Sites often pass parts of themself as a parameter in the URL. This is a potential security risk as it can be easily modified by rewriting the url in the address bar. In the logs you can often find entries like ../../../etc/passwd or http://exmpl.com/hack.txt which try to use such a vulnerability.
The file in the parameter always has to be verified if it is really part of the website. This can easily be done by putting all authorized files in a database and checking against it or by using short links instead of the parameter as then you must use a translation for the link anyway.
Short (pretty) links can also be used to hide the server side language of your site. This forces the would be hacker to try more methods to break in, not just the well known vulnerabilities of the language you used.
Cross-site scripting (XSS)
XSS vulnerability is a serious problem that needs your attention if user input is allowed on the website. All input elements that might be used for XSS attacks must be filtered before the contents are put into the database or shown on the web page. Projects like HTML Purifier can help greatly.
If you are using a previously untested system, take time to check if it has built in protection for these attacks.
Avoid custom file extensions
Do not use custom file extensions like config.inc as your web server might not be able to handle them as you intend. In the above example it might just show the contents of config.inc to anyone who types it into the address bar. If you do need them, make sure the server is set up properly.
It is extremely easy to hijack a website by uploading a file containing working php code and calling it in the browser's address bar. This file can have any extension, can masquarade easily as a txt or jpg file. All the hacker needs to do is to call this file as a parameter if the website works by passing its files in the url and he can have full file and database access.
To prevent this, the file type has to be checked and verified to make sure that it is really what it's extension describes and also only the proper file type is to be accepted.
The file parameter in the url also has to be protected by either fully eliminating it by using short links to translate them or having a database of accepted urls.
Protecting uploaded files
It is often undesireable to be able to access files uploaded into your system. This can be a security threat if the file contains executable code and you also might not want users to download content from your site without following the proper steps to do it.
Files can be protected by disabling hotlinking or you can hide them and only provide a copy with a different path on demand. The following can also be used to measure the number of downloads or applying a watermark on the fly.
File access rights
It worths taking some time and making sure that only those can access your site's files that need to. This usually means you and the apache server's user. Consult with your system administrator if you are not sure what to do.
When a website accepts user input, it should always check wheter the user is a real human being or just an automated script. Automated scripts that we usually refer to as robots are almost always trying to spam or otherwise attack our site and at the very least they take up bandwith. An unprotected questbook can have as many as a thousand entries added to it daily. This is a huge problem, even if the content has to be verified by the admin before publication.
Captchas are designed to provide a task that is simple to complete for a human, but is impossible for a computer. On a website all forms need captchas except in case of a logged in user, who already certified itself during registration.
Frequency of login attempts, form submissions
If a user tries to log in or submits a form 5 times a second, something fishy is going on. Try to set sensible limits for these events and disable access to the users IP or browser for some time to protect yourself from hackers and robots.
An automated backup solution like BackupPC is crucial both during development and after going live with the website. It is bad enough to loose what you did between two backups, but loosing everything without a backup is a tragedy and can ruin your whole company.
I belive setting up an automated daily incremental backup with 2 weeks of available restore points covers all bases. Writing a hard copy for example on bluray discs weekly is a cost effective way to have accessible backup for years.
Vulnerabilities in software are found all the time and they are often used to cause harm in systems that lack current updates. It is your responsibility to update in case there is a security fix available as soon as possible to prevent this.
In case your system depends on an older version of a software that will not be updated in the future, the system should be quarantined where minimal harm can be done if it is hacked.
Who should know what?
When you have an idea that you want to profit from, you have to protect it from others as they might decide to implement it themselves. If they have better resources, your solution will be too late to the party.
Choosing capable and reliable people for the project is essential, but even they might talk about it to relatives or collegues. Signing a non-disclosure agreement (NDA) might deter them from giving away sensitive information.
Dealing with malfunctioning or scrapped data media
Even damaghed hdds or memory cards might contain sensitive data. Always make sure to thoroughly delete or destroy them.