At the present moment, when frameworks are capable of protecting your application from injections and cross-site scripting straight "out of the box" and writing SQL all by themselves, it's quite easy to feel safe and comfortable, and lose control over your data.<br /> <br /> In a typical Web application, queries to database objects are performed by the same database user who created those object. In such case, a vulnerability in the application's code equals theft and/or destruction of all information. Experienced developers sometimes restrict privileges for performing the most "tough" command, such as DROP TABLE / DATABASE or even create separate users who are only able to read or write into specific tables.<br /> <br /> Unfortunately, even such an approach is futile. An intruder, once received access to the database under application user's credentials who possesses a read-only access, would be able to scan the whole table which could be critical and unacceptable by the business.<br /> <br /> A Row-Level Security Policy (RLS) feature was announced for the 9.5 version of PostgreSQL. However, as the bright future has yet to come, our task is to make a bulletproof back-end by employing stored procedures.<br /> <br /> How to create database users properly? How to transfer application-level logic into stored procedures and grant relevant privileges in order to protect the data sufficiently? How to test and deploy changes to back-end that was designed in such manner?<br /> <br /> All this will be the subject of our talk.