This page describes the security model used in Gears, and discusses what developers can do to build secure applications.
Gears uses the same origin policy as its underlying security model. A web page with a particular scheme, host, and port can only access resources with the same scheme, host, and port.
This means a site using Gears:
Sometimes web applications on different origins may want to share resources. We are investigating ideas for granting permissions across origins.
To protect users, Gears shows a warning dialog when a site first attempts to use the Gears API. User opt-in is important because Gears allows applications to store data on the user's hard disk.
Users can grant or deny access for each security origin. When a user grants access to Gears for a particular origin, Gears remembers this decision for future visits. Denying access is only until the page is reloaded, though users can also choose to never allow a particular site to access Gears. Remembered decisions can later be changed using the Gears Settings dialog, located in the browser's Tools menu.
Gears data files are protected with the user's operating system login credentials. Users with separate login names cannot access each other's Gears data files, as enforced by the operating system.
On the other hand, two people using the same OS login could theoretically access each other's Gears data files, just as they could access any other file on the machine.
Best Practice:: Avoid SQL injection attacks. Never insert user input directly into a SQL statement. Instead, use substitution parameters in Database.execute().
An attacker may run unintended SQL commands using a technique called SQL injection.
To avoid this, developers should pass user input to SQL statements
only through the question mark (?
)
substitution parameter. This way, the input will get correctly escaped
before being executed.
For example, write this:
db.execute('insert into MyTable values (?)', data);
instead of this:
db.execute('insert into MyTable values (' + data + ')');
Best Practice: Store offline preferences locally. Applications should treat a user's "enable offline features" choice as a per-machine setting.
Users may run your application from multiple machines, and they may not want their data stored locally on every machine. For this reason, store the choice in a local database.