Data flows can embody significant security risks that may remain undetected as security critical flow cannot be distinguished from normal usage. Passing an argument to a function that might lead to unwanted possibly security-critical behavior is called an integrity issue. Attackers can hereby achieve program reactions that the original programmer did not intend like crashes or data corruption.
When, on the other hand, a function returns data that the caller should not receive we speak of a confidentiality issue. An attacker could gain access to data that should not be revealed.
It is pretty easy to protect against either of these attacks by well-known techniques such as access control. Before anything else is done, the legitimacy of the call it checked by the function. If the privilege is not sufficient, the function will deny further execution or data retrieval effectively countering the attack.
But as programs grow during their lifetime due to the addition of new features, maintaining effective access control on every point where it is necessary is rather hard. New functions are added to the program that can make other access control checks ineffective. These functions take arguments from clients and pass them on toward pre-existing functions. These in turn check the legitimacy and only see an internal function calling them. We call these new functions “confused deputies”, as they act as intermediaries that are clearly confused about the permissions of their callers. The term was coined by Norm Hard in 1988 .
The pattern is prevailing in systems that use access control. Confused Deputy attacks is for instance what happened to Java 7 in late 2012 with exploits like CVE-2012-4681. Here the method ClassFinder.findClass was an effective Confused Deputy for Class.forName revealing Java classes that should not be available for Java Applets, making it in turn possible to circumvent Java security for Applets and allowing full access to client machines.
In this case, the confused deputy was the combination of an integrity problem and a confidentiality problem. The attacker must control the name of the class to be loaded and the deputy must retrieve and return the class that was requested.
Detecting those kind of issues with traditional methods of data flow analysis like taint analysis is possible but has two important drawbacks: insufficient tangibility of results and poor scalability (at least if the first drawback is addressed). Thus, applying them to a problem as large as the Java Class Library to prevent exploits like the above is practically infeasable.
We added a program path construction on top of the IFDS algorithm by Reps. et. al.  and its extension by Naeem et. al.  to counter the problem of insufficiently tangible reports. Furthermore, we do not do a purely forward analysis but start at a set of candidates for confused deputies and solve the data flow from the inside out. This makes the analysis much more efficient and allows for larger codebases, as we have shown by evaluating the approach using the Java Class Library.
You can read all the details in our paper:
FlowTwist: Efficient Context-Sensitive Inside-Out Taint Analysis for Large Codebases 
Or if you happen to be at FSE 2014 in Hong Kong, visit Johannes Lerch’s talk on Tuesday, November 18th 2014 at 13:30 in the Auditorium!