Rails 3 ha alcune buone protezioni attivate di default che cattureranno molti problemi di sicurezza comuni.
La codifica in uscita specifica aiuterà a mitigare gli attacchi XSS, i token CSRF sono abilitati di default su tutti i moduli che dovrebbero aiutare in questo caso, e fintanto che lo usi correttamente ActiveRecord o altri ORM possono aiutare a mitigare l'iniezione SQL.
Sul fronte della convalida dell'input ci sono ovviamente alcune cose da tenere d'occhio. Rails non eseguirà la convalida dell'input per impostazione predefinita, quindi se i dati immessi nell'app vengono trasferiti ad altre applicazioni Web, il rischio di attacchi XSS è ancora presente.
Detto questo, Rails supporta le convalide nel modello e, se possibile, ti consiglierei di eseguire la convalida della white-list degli input.
Sul fronte di iniezione SQL, è ancora possibile utilizzare SQL raw con ActiveRecord e, se lo fai, possono verificarsi i soliti problemi con SQL injection, quindi è ancora utile la convalida di tutti gli input di white-list.
Oltre a ciò ci sono ancora molte cose da guardare. l'installazione di Rails di base non fornisce autorizzazione / autenticazione, quindi deve provenire da un plug-in o essere scritta dallo sviluppatore.
Uno svantaggio degli URL stile RESTful che un'app per rails tipicamente produce è che di solito è facile per un utente malintenzionato cercare di violare l'autorizzazione modificando l'URL. Ad esempio un URL di link che mostra il primo utente, potrebbe essere facilmente modificato per avere un 2 o più. Non è che sia meno sicuro, ma rende più facile agli aggressori tentare di aggirare i controlli di autorizzazione.
Ci sono un paio di buone fonti di informazione per la sicurezza di Rails che vale la pena leggere per ulteriori informazioni.
La guida alla sicurezza delle guide di OWASP è qui e c'è anche un libro Security on Rails di Pragmatic Programmers che sebbene si concentri su Rails 2.3 ha ancora molte buone informazioni da considerare (notare che Security on Rails è ora fuori stampa).