OMG, a 15-page paper that can be summarized by one sentence every programmer should know anyway: "Sanitize your inputs!".
No framework will protect from bad programming...

The original paper is a fascinating reading http://www.cis.syr.edu/~wedu/Research/paper/code_injection_most2014.pdf

I can summarize it with, if you do something stupid in your app, like injecting data directly into the DOM, you're in danger.
Showing that a WIFI SSID containing Javascript code in it's name can be executed by an hybrid app and not by a Java or Objective-C app... brilliant!

Going back to your question: "how safe are RhoMobile apps to code injection attacks?"
With a RhoMobile app you're less vulnerable to code injections due to low-level errors that are handled by the framework and should be well ironed at this point. Building the interface in HTML5, and attaching "data" coming from the outside world to the DOM without validation... is dangerous and can beat you.

BTW, the framework include "escape_html": http://docs.rhomobile.com/en/5.0.0/guide/uichoices

If you need to output values that might contain HTML-unsafe characters, you can use ERB’s escape_html to ensure that your code is escaped properly. This will help against accidental breakage as well as intentional XSS attempts. In your controller, include the ERB::Util module and in your templates, print values with or the shorthand version

~Pietro

I don't understand this point, it sounds like nonsense. I'd like to see the details of this. Other points are well-taken.

For example, code can be injected as part of the SSID for a Wi-Fi hotspot- The biggest point of vulnerability is using the WebView to access external sites. Don't do it. External sites are more appropriately opened in the device's browser, anyway, so that it doesn't interfere with your navigation. (Seen plenty of PhoneGap apps that go off to some external site, the site has no back button, and then you have to close and re-open the app!) You might be tempted to use a Rhodes tab to load an external site. Don't!

- Next is loading the WebView directly from your own site, using http:. Don't. Use https:

- While I wouldn't consider it a vulnerability (if you've minded the points above) it would enhance security to not use the Javascript APIs. Use the Ruby APIs. The less power available fromJavascript the better.

- Keep in mind, as well, that all of your controller endpoints can be accessed from javascript, and create an informal and probably poorly-documented "api". You can enhance security by making internal controller methods that do not need to be accessed from the WebView private. They won't be accessible from the webview.

- In many cases (depending on platform) users can attach a USB cable and use remote browser inspection tools. Consider if you might have hostile users. This will give them a great deal of access. A USB cable and Safari Web Inspector or Chrome Developer Tools make the "random" server port easily discoverable. The user can then observe interaction between the WebView and the Rhodes server and look for vulnerabilities. Which in typical apps I presume would be numerous. Is a Rhodes app a closed system? In most cases, no. Can you rely on your Javascript code that validates form values? No.

- Note that if you enable the Javascript API, then a user with a USB cable, inspection tools, and Rhodes documentation can do as he pleases and make any Rhodes API call whatsoever. (I'm unaware of what options may be available for locking this down - say, on specific security-enhanced Android, etc.) I think this can be locked-down for iOS for managed devices. (e.g. corporate-issued device where the company uses Apple's device-management software.)

- In general, it will enhance security to work in Ruby as much as possible. The Ruby code is compiled to byte code and not easily read. There is no way to usefully "debug" the Ruby code, but a user with a USB cable and easily available tools can view your Javascript code, set breakpoints, look at values, etc. How many of us validate all form fields in Ruby, in addition to any validation we do in Javascript for the user's sake? If you want tight security, you have to treat the WebView just as you do a browser for a conventional website. JS validation is for the user. Server (in our case) Ruby validation is for security and integrity.

- Don't do Ajax to external sites or even your own in Javascript! Not if there is any security issue at all. (Is there a password? Some other kind of authentication?) Access the external site in Ruby code (which also solves CORS issues.)