This documentation refers to an older version of CiviCRM (3.4 / 4.0). View latest version.

Aller directement à la fin des métadonnées
Aller au début des métadonnées
This page refers to CiviCRM 3.4 and 4.0, current STABLE version.

Documentation Search

CiviCRM 3.4 and 4.0 Documentation

Support and Participation

Developer Resources

CiviCRM books!

Make sure to check out the FLOSS Manual Understanding CiviCRM as well! You can also support this project by ordering a hard copy.

Or support us by buying an eBook or hard copy of Using CiviCRM from Packt Publishing.

Scope and Intent of this Section

This section is intended as a starting place for conversation/thinking - not as a definitive statement regarding security issues for CiviCRM or other networked applications. Data and network security is a complex field - and you should consult with security expert(s) regarding your particular needs and implementation.
Content Contributed by: Dan Robinson (dan at civicactions dot org)

PCI Data Security Standards notes contributed by: Joe Murray (joe dot murray at jmaconsulting dot biz)

Updates on PCI DSS and PCI-PA DSS by Kasia Wakarecy (kasia at freeform dot ca)

PCI Data Security Standards for sites with CiviContribute and CiviEvent

American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. work together on standards for online payment processing (see They have upped the requirements and process for accreditation of your site as of the Spring of 2008.

Your hosting for sites that accept payments using CiviContribute and CiviEvent should comply with their standards if the plug-in you are using does not route the user to external pages for payment processing (eg PayPal Standard makes users go to PayPal pages to pay before coming back, other plug-ins like PayPal Pro, Moneris and IATS allow users to stay on your site's pages with your branding; the latter sites should comply with the PCI Data Security Standards). provides more information on what you should be doing, eg ensuring that the database is served from a different server than your webserver is on, and that your web server is not also serving mail to users.

In addition to PCI Data Security Standards (PCI DSS) that require hosting infrastructure to be secure, there are PCI Payment Application Data Security Standards (PCI PA-DSS: PCI PA-DSS relates to the website applications, which means CiviCRM and/or Drupal/Joomla would have to be PCI PA-DSS compliant if a site with that platform is using an above mentioned plug-in to process credit card within the site. The problem with that is that since CiviCRM, Drupal and Joomla are open source systems, theoretically each installation would have to be tested - because each installation can have different modules installed, custom code and can be configured differently. On top of that, the PCI testing has to happen every 4-12 months, depending on the number of processed transactions. Additional discussion about PCI compliance is available on the CiviCRM forum

Should I Consider Using SSL for a CiviCRM Site?

SSL covers a set of somewhat limited security issues. In fact it addresses three problems (and btw I am not a security pro- so don't take anything I'm saying for revealed truth)

  • Data Security - Whether or not your data can be read by unauthorized users.
  • Data Integrity - Whether or not the data you send is the data that the requestor retrieves.
  • Establishing Identity - Are the sender and reciever who they say they are?

SSL is typically implemented with "Server side authentication" - in other words the server has a certificate (which you can trust or not) and the client is anonymous - this essentially means that the client is safe from a bad server, but not the other way around. SSL will deal fairly effectively with "man in the middle" attacks (where someone places a device or program between sender and receiver and "sniffs" the line for communication). Two common points of vulnerability are:

  • One of the computers engaged in the conversation has malicious software (e.g. a "root-kit") installed on the local machine listening to the communication. - SSL might not fix this problem.
  • Someone is listening from another machine on the LAN or on the network hardware itself (SSL would help here). This is actually pretty easy to do if you are not specifically watching out for it. Pre-wireless this was a relatively complicated attack. The attacker had to position themselves "on the line". Now with wireless this is a big problem. Take the situation where someone parks their car outside of a key staff person's house who is accessing via unsecured wireless.

Your decision to use SSL certificates with CiviCRM will rest on your payment processor mechanism, and the level of security you require for the personal information you will be managing.  One type of payment processing mechanism involves collecting all transaction information, including credit card numbers, in a CiviCRM form then submitting to the payment processor.  The second type of payment processing mechanism redirects to an external secure transaction site to collect credit card information.  The different cases are:

  1. Credit card information collected in CiviCRM forms.  Use SSL
  2. Credit card information collected on external site. Information in CiviCRM is sensitive.  Use SSL
  3. Credit card information collected on external site. Information in CiviCRM is not sensitive.  Optional use of SSL

 How Do I Install SSL on My Site?

  1. Determine what your server requirements or procedures are for enabling an SSL certificate.  On shared servers this may require purchasing a static IP from your host. Important: Your host must be willing to install the certificate on your domain, not one at a higher level. CiviCRM does not support shared SSL.
  2. Purchase an SSL certificate from one of the security vendors.
  3. Install the SSL on your server following procedure you learned in step 1.
  4. Enable "https" redirection on your CiviCRM site so that the desired pages use SSL encryption. CiviCRM has an option in global settings to enable SSL redirection. As of CiviCRM 2.0 this has limitations in that it doesn't redirect back on "http" once the secure pages are left.  For Drupal users, a better solution is to use the "Secure Pages" module, and another option is to use apache mod_rewrite.  (see this forum topic,1692.0.html for a discussion of both methods)

What Else Should I Be Thinking About?

So SSL (and other data protection measures) can help in some of these circumstances. But in my opinion this is not where you will see the most common attacks. Those will be directed at the data itself - which live on the host and client computers. These attacks require a lot less sophistication and are a lot less dangerous for the people doing the dirty work. To protect against this sort of attack you will want to consider the following -

1. Policies - Everything from who gets what kind of permissions to how you treat passwords. Password policies are critical (IMHO) - because
this is where you are very likely to see an attack. Some guidelines regarding passwords -

  • Are they long/obscure enough?
  • Are they ever transmitted via cleartext (without encryption)? Chat logs, and email DBs are full of unencrypted passwords.
  • Do users keep them in a digitally secure store or are they written down in people's daily planners?
  • Are they changed when people leave the organization?
  • Are your backups secured?
  • Do you have policies regarding creation and storage of non-backup copies of DBs?

2. Network security -

  • Is your network hardware being kept updated - there are routinely security holes found in the software/firmware in the products of major
    brands of network suppliers.
  • Is your network being actively monitored for intrusion / sniffing?
  • Are all the other computers that you share local network resources with secured?

3. System security -

  • Is your OS up to date?
  • Are all unnecessary services turned off?
  • Are your IP ports being actively scanned and monitored?
  • Is your system adequately partitioned so that successful attacks on one users or clients account will not effect other accounts?

If you don't believe that individual's computers can be hijacked take a look at these:

Also if you are serious about protecting a sensitive (political) clients business from cyber attack you should also consider -

  • Denial Of Service attacks
  • Ability to restore from catastrophic failure

What's Next?

So what's a reasonable solution? Get a security audit and then outsource! Very few organizations have the time or expertise to deal with these issues in a comprehensive or effective way. If you want to find out how vulnerable you are then have a pro do an audit. If you want to build a secure environment yourself - great - but you will spend lots of time and money doing so. Find a host you trust and let them do the heavy lifting for you. You will still have to implement decent organizational policies however - otherwise your security is useless.

To re-cap - is SSL the way to go? Probably - for the specific problems it fixes. The analogy is that you can place a really big lock on your door - but if the window is left open and the alarm is turned off then you shouldn't have a lot of confidence in your solution.

  • Aucun