<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>security on DataScience.LA</title><link>https://datasciencela.github.io/tag/security/</link><description>Recent content in security on DataScience.LA</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>DataScience.LA, 2014–2021 · Read-only archive: comments are closed.</copyright><lastBuildDate>Mon, 12 Jan 2015 09:41:19 -0800</lastBuildDate><atom:link href="https://datasciencela.github.io/tag/security/index.xml" rel="self" type="application/rss+xml"/><item><title>Secure your Shiny apps (against SQL injection)</title><link>https://datasciencela.github.io/secure-your-shiny-apps-against-sql-injection/</link><pubDate>Mon, 12 Jan 2015 09:25:12 -0800</pubDate><guid>https://datasciencela.github.io/secure-your-shiny-apps-against-sql-injection/</guid><description>&lt;p&gt;&lt;a href="http://shiny.rstudio.com/"&gt;Shiny&lt;/a&gt; takes inputs from UI elements and sends them to the server, where the application can access them as R variables. While Shiny has security measures in place, as in any typical web application, it remains the developer&amp;rsquo;s responsibility to sanitize the inputs before using them. For example, Shiny has no way to protect you if you are using an input in a SQL query such as &lt;code&gt;select ... from ... where field = 'input'&lt;/code&gt;. Someone manipulating the websocket communication can craft a specially-formatted input that can force the database to execute a query that it is not supposed to do, termed an &lt;a href="http://en.wikipedia.org/wiki/SQL_injection"&gt;SQL injection&lt;/a&gt;. This might give an attacker access to private data or the ability to do other nefarious things, and it is a common security issue.&lt;/p&gt;</description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://datasciencela.github.io/secure-your-shiny-apps-against-sql-injection/feature.png"/></item></channel></rss>