# How does Discourse guard against SQL injections via the user agent?

**URL:** <https://meta.discourse.org/t/how-does-discourse-guard-against-sql-injections-via-the-user-agent/177251>\
**Category:** Feature\
**Created:** [January 26, 2021, 12:43am UTC](https://meta.discourse.org/t/how-does-discourse-guard-against-sql-injections-via-the-user-agent/177251 "2021-01-26T00:43:01Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![neounix](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/neounix/32/215617_2.png) [@neounix](https://meta.discourse.org/u/neounix)\
**Post date:** [January 26, 2021, 9:32am UTC](https://meta.discourse.org/t/how-does-discourse-guard-against-sql-injections-via-the-user-agent/177251/3 "2021-01-26T09:32:35Z")

</div>

> [@mbaker341997](#):
>
> I was wondering if Discourse has any measures in place to guard against these kind of attacks?

Hi @mbaker341997

The Rails security guide is a good overview, but in my view, the Rails security guide does not adequately cover what many consider (arguably) the most important control for mitigating against an SQL injection attack.

The first line of defense against “SQL injection” is strong input data validation.

Let me give you a direct example from the Rails security guide (above);

The Rails security guide shows this simple example:

```plaintext
Project.find(:all, :conditions => "name = '#{params[:name]}'")

```

which can be exploited by injecting into the input params:

```plaintext
’ OR 1=1’

```

However, this can be prevented by having strong validation in the model, for example:

```plaintext
before_validation :filter_name_param

private

def filter_name_param

   ### your custom params filter code here to insure special chars and other "dangerous 
   ### code" is not permitted anywhere near the database

end

```

Rails has a lot of “out of the box” validations which can (and should) be included in models to insure input params are validated long before they have a chance to enter the DB.

Here is more on Rails validation here:

> **[Active Record Validations — Ruby on Rails Guides](https://guides.rubyonrails.org/active_record_validations.html)**
>
> This guide teaches you how to validate Active Record objects before saving them to the database using Active Record's validations feature.After reading this guide, you will know: How to use the built-in Active Record validations and options. How to...

Many people forget that input data validations are the first line of defense against SQL injection attacks, and this is true of all server side web-dev code like Ruby, PHP, Python, etc. Generally speaking, client-side validation can be exploited and must be also validated on the server side.

In particular, I recommend reading the “Custom Validations” section:

> **[7. Performing Custom Validations - Active Record Validations — Ruby on Rails...](https://guides.rubyonrails.org/active_record_validations.html#performing-custom-validations)**
>
> Here's an example of a very simple validation: | This guide teaches you how to validate Active Record objects before saving them to the database using Active Record's validations feature.After reading this guide, you will know: How to use the...

HTH

---

_[View the full topic](https://meta.discourse.org/t/how-does-discourse-guard-against-sql-injections-via-the-user-agent/177251)._