Hello all,
I am all set to launch a website on which i have been working from months but now am afraid how safe it might be once it gets attention of hackers . As most of the code in website is in PHP,html,mysql i am posting this in this forum so that i can get suggestions from you all. Websites that are developed by Big companies might undergo testing from various testing tools , tests from hired ethical hackers ,etc, before getting launched where as what about websites that cant afford all those expensive methods. I understand that without undergoing all those procedures no website could be hacker safe but any suggestions about measures to be taken before launching a website would be appreciated.
Thank you all in advance.

Ask your self

  1. Did you do everything to prevent SQL injection
  2. Do you use id values as indentificators, did you secure option for array exploit
  3. Are you using RSS feeds, are they secure
  4. Hosting, who is responsible for website security? You or your web hosting company? Are the folder permission set correctly?

That is just few things you should look into...

commented: thnx for your time, I shall look for all the security measures you have mentioned +1

Take a look here for a couple of small functions that will help you, in terms of handling user input.

Also, if you're passing a variable from $_GET, then you can use a type-finding function to help your security. Eg. if you have something like "?id=53" in your URL, then you can just check it using the isnumeric() function. Then no hackers will have a chance.

Remember, if you have no user input, then you'll be perfectly safe. But if you have input, then remember the number one security rule (well, mine, anyway): you can never trust the user.

commented: thnx for you time, found the link helpful +1

Thank you peter_budo, Demiloy and Shanthi for your time.
I shall look into all those security measures now and shall make sure I complete all of them before releasing the site.
If anybody knows some more security measures that are to be taken before launching a website please share them here.
Appreciate your time in advance

Thank you


  1. Do you use id values as indentificators, did you secure option for array exploit


    Hi peter_budo,

    Can you please tell what are indentificators..

    Thanks in advance

I can not remember exactly what was it but it had something to do with "id" passing values in following format WEB_ADDRESS/page.php?id=32, when adding square brackets [] after "id" will show site structure. I will try to find where I read about it and let you know.

I can not remember exactly what was it but it had something to do with "id" passing values in following format WEB_ADDRESS/page.php?id=32, when adding square brackets [] after "id" will show site structure. I will try to find where I read about it and let you know.

Again, I think if you just check it using is_numeric, you should be fine.

commented: thnx it worked +1

thnx Demiloy & Peter_budo I made use of is_numeric().

Now,
when user manipulates the url like,

when the url is www.example.com/xyz.php/userid=22

how to avoid displaying results when user changes the userid from 22 to someother number in the url.

Basically, my site has a search page, when on submitting the username in search, if username exists then linnk is given.

when clicked ,www.example.com/xyz.php/userid=22 appears in the address bar.

how to avoid displaying results when users manipulates the userid there?

Anyhelp is apreciated.

Thankyou all.

You do not want to keep user identification as part of the URL. Put these data into session.

Also, session variables can be exploited if you are in a shared hosted environment.

Someone with ssh access to the shared server can get a valid session id from where PHP stores them and pretend to be authenticated. A way to work around this is to store the IP address of the user at login, and keep checking it on every page. If the IP address changes during the session, require the user to re-login. (Obviously, don't store it in the session variable, but store it in the database).

BTW, this only applies to if you're using shared hosting.

commented: Thankyou scru, shall add this. +1

yes,... scru is damn right...
kavitha,keep that point in your mind...

commented: sure shanthi :) +1

Also speaking of session exploitation, if you post any user input directly to the webpage, make sure to use htmlentities() to verify that no javascript is being slipped in. This will also ensure that someone can't disrupt your html page structure.

commented: Indeed. +3
commented: shall replace all user inputs with html entitites. thnx for you time +1

sure Shanthi,Robbob and scru, I shall work on that too.. shall add the logic you mentioned Scru.
Thankyou :)

Odds are, if you are certain that SQL and XSS injections aren't going to happen, you should be fine. There is the chance your server isn't secure, too, but if you aren't hosting yourself, that shouldn't be too big of a threat.

Good luck!

> A way to work around this is to store the IP address of the user at login, and keep checking
> it on every page.

And what are you going to do about users who are behind a common proxy which is almost the case with all corporate organizations. Employees never directly connect to the internet, it's always done via a proxy, so a IP address based solution is as brittle as it gets.

commented: sure, i shall take care of that now +1

> A way to work around this is to store the IP address of the user at login, and keep checking
> it on every page.

And what are you going to do about users who are behind a common proxy which is almost the case with all corporate organizations. Employees never directly connect to the internet, it's always done via a proxy, so a IP address based solution is as brittle as it gets.

What I have done before is just pull a timestamp and innitially add it to session and database record. The the next page request I pull the timestamp record from the database, compare it with the session, if the two match, pull the most current timestamp, replace the session timestamp and the database timestamp with the most current and allow access. If they don't compare I force a login for that user.

What I have done before is just pull a timestamp and innitially add it to session and database record. The the next page request I pull the timestamp record from the database, compare it with the session, if the two match, pull the most current timestamp, replace the session timestamp and the database timestamp with the most current and allow access. If they don't compare I force a login for that user.

Though it means that for *every* request you end up making an extra database read and write call. Though it might be a really good solution for normal sites, high traffic sites can't afford this overhead. Yes, there has to be a better way of doing it. :-)

The distinct advantage of using mature technologies is that you don't have to worry about such details, you pay for it and you get the service. For e.g. when developing a J2EE application using the IBM stack, a few configuration changes here and there using the administrative console of the Application Server and you are good to go with Single Sign On, Session management and the likes.

commented: High traffic sites shouldn't use shared hosting. +3

Though it might be a really good solution for normal sites, high traffic sites can't afford this overhead.

This is something that I strongly anticipate getting experience with.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.