THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
This is still a WIP page but be sure to read at least the "Be safe" Warning
What is this page about?
This page is about security as in "external security". In other words it's not about authentication nor authorisation, for that refer to OFBiz Security Permissions.
But about about keeping your OFBis instance secure from external exploits, and prevent vulnerabilities as soon as they are known.
You can trust the Apache OFBiz PMC Members and Committers, we do our best to keep OFBiz secure. But despite our best efforts we migth sometimes overlook a security issue. In such cases, as explained at https://ofbiz.apache.org/download.html, we strongly encourage OfBiz users to report security problems affecting OFBiz to the private security mailing list of the ASF Security Team, before disclosing them in a public forum. Please see the page of the ASF Security Team for further information and contact information. Also in case of doubt, refer to the current page where quick fixes not already released might be explained.
Though it's maybe not totally complete, you might refer to for details on security.
The 2015 infamous Java unserialize vulnerability
Sometimes the OFBIz code itself is not the culprit. OFBiz relies on many Java librairies, and if one of them has a flaw we can't always wait it's fixed to warn and protect our users. This is for instance what happened with the 2015 infamous Java unserialize vulnerability. OFBiz was affected by 2 librairires: Commons Collections and Groovy . As you can see at OFBIZ-6726, we waited the Commons Collections update to fix the issue, because it was not much disclosed then. But with the article above the buzz began to spread and we could not wait to be able to update Groovy. So a temporary workaround was adopted as explained in OFBIZ-6568.
Be safe!
Until we update the Groovy librairy, we recommend you to have a look at http://svn.apache.org/viewvc?view=revision&revision=1717058 and so to use the start-secure ant target rather than the start one, or any other possibilities offered by OFBIZ-6568 (startofbiz.sh/bat, etc). Actually it's just a matter of calling "-javaagent:pathTo/contrast-rO0.jar" in your starting script. Also to have an historical view on the OFBiz security you can refer to
From what you can see there you can secure OFBiz using "-javaagent:pathTo/contrast-rO0.jar" in your starting script" and you will be covered from these vulnerabilities which exist OOTB as long as we don't solve OFBIZ-6568.
- org.codehaus.groovy.runtime.ConvertedClosure
- org.codehaus.groovy.runtime.MethodClosure
Those are already covered by OFBIZ-6726
- org.apache.commons.collections.functors.InvokerTransformer
- org.apache.commons.collections4.functors.InvokerTransformer
- org.apache.commons.collections.functors.InstantiateTransformer
- org.apache.commons.collections4.functors.InstantiateTransformer
We don't use
- org.springframework.beans.factory.ObjectFactory
But if you do you be sure to fix your issue or use "-javaagent:pathTo/contrast-rO0.jar" in your starting script"
RMI and JMX
If you use RMI or/and JMX you are also at risk!
I will soon replace contrast-rO0.jar by notsoserial-1.0-SNAPSHOT because it covers one more class (com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl) and I find the explanation there very clear
Another option is to put the xalan class in the contrast-rO0.jar blacklist. You should also add all new vulnerable classes in the blacklist or update the jar.
Another mean is of course to give your own whitelist. Both solutions allow that, but notsoserial provides the "dryrun" option which makes things easier.
Who is concerned?
Roughly there are 3 categories of OFBiz users:
- Those who use OFBiz only in an internal manner, without any connections with the Internet, most of the time only the OFBiz backend is then used. They should be the less concerned.
But this category tends to be less and less represented. Nowaydays most of the organisations need somehow to be connected. - Users working in a secured environment, notably through firewalls and proxies. They should less fear security vulnerabilities. But you can't never be sure, black hackers are always trying...
- Users working in a less secure environment. For instance using the Out Of The Box (OOTB) OFBiz ecommerce/ecomseo solutions with a direct access from the Internet to it.
In any cases, always check that your version is up to date, see the "Security Vulnerabilities" section at https://ofbiz.apache.org/download.html. If you use the trunk be sure to closely follow JIRA issues and revisions commits regarding security and check OFBIZ-1525. Then apply security patches as soon as possible, and of course check this page! 
How to check yourself, and possibly share and help
Now you might wonder how to yourself keep your own OFBiz instance safe from vulnerabilities and maybe how to contribute your experience to other OFBiz users. Having worked on the OFBiz security for few years, these are the tools I (Jacques Le Roux) personnaly recommend. For each it's explained in specific pages how they work and how to share your results.
- For Java: OWASP Dependency Check Since it reports a lot of false positives or issues not really needing our attention, this page explains how to use it and to share results: About OWASP Dependency Check
- For JavaScript: Retire.js see this page: About retire.js
- For HTTP headers: https://cyh.herokuapp.com/cyh. This page gives more information: How to Secure HTTP Headers
There are other web oriented, tools like OWASP Zed Attack, Beef or IBM Security AppScan. But most of the time they are too general, and totally parsing OFBiz can take a lot of time or be quite a challenge if done manually. You can find more penetration tools here
In December 2015, I ran (Jacques Le Roux) a complete (100%) OWASP Zed Attack automated (Quick Start) penetration session against a locale instance of OFBiz backend (trunk head) running on localhost. It started with the same link used for backend demos. No major flaws were discovered.