Web publishing security considerations
Any databases enable you to publish to your intranet or the Internet, so that users can browse, search, and update the databases using web browser software. This introduces more risk than sharing files with other clients on the server.
Tips and considerations when designing databases for web publishing
1. Define accounts and privilege sets.
•Protect all files with user names and passwords. You can create a Guest account, which logs in with a default user name and password, if it’s not practical to use unique accounts for clients.
However, this makes your file available to anyone who has the IP address or domain name of the computer hosting the database.
•Assign privileges to modify data and database structure only if necessary.
•Enable only the required web publishing extended privileges.
2. If you are updating your database, make sure all of your security protocols transfer over and are still in place. Don’t take it for granted that you have migrated it from one to the next.
3. With some databases, you can only publish files on the web from the host computer.
4. In some databases, all layouts are available to web users, based on their accounts. You can restrict layouts for accounts with privilege sets, but you should not rely on layouts for security. Manage access to data with tables, records, fields, scripts and value lists for the best security.

Considerations when hosting files on a database server
Keep the following points in mind when hosting databases on a server:
•If you enable remote access, be sure to require a password.
•Store files on a local server (not on network directories). One of the most important performance factors is reading and writing data quickly to disk.
•Disable file sharing or ensure that files hosted by the server cannot be accessed directly by users.
If a file can be copied from a file server, it is vulnerable to attack “off line.” For example, group names for accounts authenticated with the external server feature are stored as text strings. So if the group name is reproduced on another system, the copied file can be accessed with the privilege set assigned to the members of the group, which might expose your data inappropriately.
•Suppressing a filename is not a replacement for using accounts and privileges to protect a file.

Tips for creating effective passwords
•Secure passwords are more than eight characters in length, and include mixed upper and lowercase letters and at least one numeric digit. Consider combining two unrelated words, and swapping letters out for numbers, for example, b0att!me (swapping a zero for “o” and an exclamation point for an “i”).
•If files are web-published, account names and passwords should only use printable ASCII characters, for example a-z, A-Z, and 0-9. For more secure account names and passwords, include punctuation characters such as “!” and “%,” but do not include colons. If you’re hosting databases with a server, enable SSL encryption.
•Passwords are less secure when they include strings that are easily guessed, such as names (especially the names of family and pets), birth dates, anniversary dates, and the words password, default, master, admin, user, guest, client and similar standard terms.
•Change passwords frequently, perhaps every 30 or 90 days.
•Use passwords only once.
•Wherever possible, assign a unique password for each user. If you must share user accounts, be sure to change the password regularly.
•Do not record your passwords in a master file or list unless the file or list is well secured.
•Do not share user accounts with other users; users should only receive account names and passwords from file administrators.

Here is an interesting article about the losses that advertisers might sustain as a result of the way that Chrome handles pop ups:

Concerns for Advertisers about Chrome

<a href=”http://www.informationweek.com/news/internet/google/showArticle.jhtml?articleID=210300377″>http://www.informationweek.com/news/internet/google/showArticle.jhtml?articleID=210300377</a>

Tips for restricting file access
•Avoid automatically logging in with an account name and password specified in the dialog box
•Using the same password in each file is often convenient when users must interact with several solution files in once session. This no longer works when users change their own password (unless they change them in all files). When you create accounts, you must create them in all solution files.
For convenience, you can define multiple tables in one file. Consider hosting files on a server and using an external authentication server, such as Windows Domain or Apple OpenDirectory.
•If accounts are used by multiple people, change the password on a regular basis. Also, change the account name and password when people leave the group.
•Create a startup file that only interacts with critical files via scripts. The startup file doesn’t store data; instead data is moved to more critical files via scripts. Have users open the file with the default account name and password that restricts access to sensitive data and risky features, like deleting records. The scripts can perform actions you would not provide users access to, like deleting records, by enabling Run script with full access privileges.
•You can set record access privileges to view, edit, and delete certain records within each table. Limit users’ access to specific records based on a number of criteria, for example their department, job title, job responsibilities, and so on.
One thing to note: Limiting access to specific records introduces a much more complicated data access model. Thoroughly test your solution by logging in with different user accounts and evaluating all layouts, reports, and scripts. Be sure to document the specific conditions so users will know what to expect.
•Don’t use layouts for security. The only way to protect files, for example from CGI requests or other sources, is by restricting account access on a field-by-field or table basis.

*Permanently remove the Full Access privilege set and any accounts that are using the Full Access privilege set (including the Admin account). This action cannot be undone. It should only be done when you are certain no one will need to have full access to the file again.