攻擊者會創建一個意想不到且貫穿于整個應用程序的控制流路徑，從而逃避潛在的安全檢查。
若攻擊者可以為應用程序提供確定實例化哪個類或調用哪個方法的參數值，那么就有可能創建一個貫穿于整個應用程序的控制流路徑，而該路徑并非是應用程序開發者最初設計的。這種攻擊途徑可能使攻擊者避開 authentication 或 access control 檢測，或使應用程序以一種意想不到的方式運行。
如果攻擊者能夠將文件上傳到應用程序的路徑或者庫路徑上顯示的位置，那么對應用程序來說，情況會非常糟糕。無論處于上面哪種情況，攻擊者都能通過反射將新的行為引入應用程序，而這一行為往往可能是惡意的。
例：應用程序使用反射 API 的一個共同理由是實現自己的命令發送器。下面的例子顯示了一個 JNI 命令發送器，它使用反射來執行 Java 方法，該方法由讀取自 CGI 請求中的數值進行驗證。執行該代碼允許攻擊者調用在 clazz 中定義的所有函數。
char* ctl = getenv("ctl");
...
jmethodID mid = GetMethodID(clazz, ctl, sig);
status = CallIntMethod(env, clazz, mid, JAVA_ARGS);
...
[1] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A1 Unvalidated Input
[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A4 Insecure Direct Object Reference
[3] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A4 Insecure Direct Object References
[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3570 CAT I
[5] Standards Mapping - Security Technical Implementation Guide Version 3.4 - (STIG 3.4) APP3510 CAT I, APP3570 CAT I
[6] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 470
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.4
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.1
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.8
[10] Standards Mapping - FIPS200 - (FISMA) SI