1+ select ' shell' as component,
2+ ' SQLPage safety' as title,
3+ ' shield-check-filled' as icon,
4+ ' /' as link,
5+ ' en-US' as lang,
6+ ' SQLPage security guarantees' as description,
7+ ' documentation' as menu_item,
8+ 20 as font_size,
9+ ' Poppins' as font;
10+
11+ select ' text' as component,
12+ '
13+ # SQLPage' ' s security guarantees
14+
15+ SQLPage is a tool that allows you to create a full website using only SQL queries, and render results straight from the database to the browser.
16+ Most programmers, hearing this, will immediately think of the security implications of this model.
17+
18+ This page is here to provide a list of the security guarantees that SQLPage provides.
19+ SQLPage was designed from the ground up to be usable by non-technical *data analysts* and other non-web-developers,
20+ so it provides safe defaults everywhere, so that you don' ' t have to worry about inadvertently
21+ exposing more data than you intended.
22+
23+
24+ ## Protection against SQL injections
25+
26+ SQL injections are a common security vulnerability in traditional back-end web development,
27+ that allow an attacker to execute arbitrary SQL code on your database.
28+
29+ **SQLPage is immune to SQL injections**, because it uses [prepared statements](https://en.wikipedia.org/wiki/Prepared_statement)
30+ to pass parameters to your SQL queries.
31+
32+ When a web page starts rendering, and before processing any user inputs, all your SQL queries have already been prepared, and no
33+ new SQL code can be passed to the database. Whatever evil inputs a user might try to pass to your website,
34+ it will never be executed as SQL code on the database.
35+
36+ SQLPage **cannot** execute any other SQL code than the one you, the site author, wrote in your SQL files.
37+
38+ If you have a SQL query that looks like this:
39+
40+ ```sql
41+ SELECT * FROM users WHERE userid = $id;
42+ ```
43+
44+ and a user tries to pass the following value to the `id` parameter:
45+
46+ ```
47+ 1; DROP TABLE users;
48+ ```
49+
50+ SQLPage will execute the search for the user with id `1; DROP TABLE users;` (and most likely not find any user with that id),
51+ but it *will not* execute the `DROP TABLE` statement.
52+
53+ ## Protection against XSS attacks
54+
55+ XSS attacks are a common security vulnerability in traditional front-end web development,
56+ that allow an attacker to execute arbitrary JavaScript code on your users' ' browsers.
57+
58+ **SQLPage is immune to XSS attacks**, because it uses an HTML-aware templating engine to render your SQL results to HTML.
59+ When you execute the following SQL code:
60+
61+ ```sql
62+ SELECT ' ' text' ' AS component, ' ' <script>alert("I am evil")</script>' ' AS contents;
63+ ```
64+
65+ it will be rendered as:
66+
67+ ```html
68+ <p>
69+ <script>alert("I am evil")</script>
70+ </p>
71+ ```
72+
73+ Additionnally, SQLPage uses a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)
74+ that disallows the execution of any inline JavaScript code, and only allows loading JavaScript code from trusted sources.
75+
76+ If you have some legitimate JavaScript code that you want to execute on your website, you can use the `javascript`
77+ parameter of the [`shell`](documentation.sql?component=shell#component) component to do so.
78+
79+ ## Database connections
80+
81+ SQLPage uses a fixed pool of database connections, and will never open more connections than the ones you
82+ [configured](https://github.com/lovasoa/SQLpage/blob/main/configuration.md). So even under heavy load, your database
83+ connection limit should never be saturated by SQLPage.
84+
85+ And SQLPage will accept any restriction you put on the database user you use to connect to your database, so you can
86+ create a specific user for SQLPage that only has access to the specific tables you will use in your application.
87+
88+ If your entire application is read-only, you can even create a user that only has the `SELECT` privilege on your database,
89+
90+ ' as contents_md;
0 commit comments