What are the security concerns that I need to look out for with Java Persistence API (JPA)

I'm starting to learn JPA, and I have a considerable amount of legacy EJB2.0 code that will need to be refactored to use the new features, as well as any new functionality that I will add to the code base. Are there new attack vectors that I will need to account for in my c开发者_运维技巧ode, or will defensive programming cover me?

JPA is like JDBC: a backend technology. The same security concerns that apply to JDBC apply to JPA. So most security consideration will be implemented on the application level or are handled by front end API’s. But indeed JPQL injection is an obvious ones you should be aware of.

JPQL injection:

Just like when using SQL or the JDBC API, you should never directly add your parameters to a query String. You should work with the setParameter on the Query object (applies to both adhoc and named queries) or you could use the JPA criteria API (although named queries offer the best performance).

Query query = em.createQuery("DELETE Order WHERE customer = :customer");
query.setParameter("customer", customer);
query.executeUpdate();

Database rights:

For extra security, you could make multiple persistent units (PU) so the impact of any security breaches is limited. For example you could create multiple PU's with different database access rights: one with update rights and another with read only query access. Just realize that decisions like this will impact your application design.

If you are deserializing an object from bytes that you received from an untrusted source, then it can cause any class on the boot classpath to load, whether public or not, and cause that classes initialization to run. It can also gain authority via constructors with side-effects and via custom deserialization methods.

If your classpath includes well known public classes with unbounded authority, like the Rhino interpreter shipped with most recent JVMs, or the javax.tools interface to javac, AND that authority is reachable via the constructor of a serializable class, then an attacker could use that to execute arbitrary java code. In practice, this means arbitrary user-ring code with the privileges of the current user via java.lang.Runtime.

The first criterion is easily met. The second one is probably much less easily met.