I will have a LAMP web server with CentOS and cPanel. With this setup, is it possible for any server log files, whether regular or error logs, to contain sensitive information in them, such as passwords or url variables (GET data)?

What I'm trying to avoid is having sensitive information stored in a plain text log file.

If the server does do this, how do I stop this? Is it a good idea to do so for security?

  • Yeah, you can just change the apache common or custom log, to log just the vhost name and not the full URI with session ids and tokens. Commented Aug 7, 2012 at 21:37

2 Answers 2


Yes, it's possible it may contain sensitive information. A lot depends on what you consider 'sensitive'. That the IP address access www.hotpron.xxx at 7pm on Sunday contains no user identifiable information but might be extremely sensitive to someone.

The normal logging provided by Apache will only record

  • GET variables
  • any cookies you explicitly include in the log format

It will also record usernames used for authentication by the webserver (rather than the code itself) via the mod_auth add ons. Again this is configurable.

And the error log will contain anything your application chooses to write to it.

It's possible to get it to log POST variables as well using (e.g.) mod_security - but this is more involved.

Generally most people would consider it very bad practice to pass authentication tokens (usernames, passwords, session identifiers) via GET variables.


First, I would do my best to try to not log sensitive information outside of the (protected/encrypted) database. This can typically be accomplished by

  • Not using http GET to send passwords/other sensitive information (e.g., credit card #s) to your site. E.g., by clicking a button that goes to a URL like https://www.example.com/login?user=admin&password=dumb_password that then forwards you to the site as a logged in user. Most web servers (apache) default configuration will log this GET request with the parameters in cleartext. Use POST (so its not plaintext logged) and do it over HTTPS (to prevent network eavesdropping) with properly signed certificates (to prevent Man in the Middle attacks).

  • Not logging the contents of http POST (unless you are debugging something during development). This is usually not done by default.

  • Not logging the contents of session cookies or allow reuse of one-time tokens (e.g., from password resets) that may be logged.

Still sensitive information can inadvertantly get into your log files. A common example is user authentication via ssh. Every now and then a user will be in a rush to login and type their password in the (logged) username field press enter, and their password will be logged in the user field secure.log (or auth.log in some linux flavors). So its best to prevent non-root users from being able to read these log files in the standard way. (That is standard file access controls with chmod, chown, chgrp, and with full disk encryption if you are worried about someone removing the hard disk or booting into single user mode).

Finally, have a look at your log files and see what you are logging. Search (grep) through them and make sure nothing shows up in plaintext that shouldn't be logged (e.g., create a fake account with fake confidential information go through the full process and see if you can find any part of the fake information). I say a fake account, because searching for real confidential information may put that information in a different log file (e.g., shell's ~/.history file).

  • I don't understand "Not logging the contents of session cookies or allow reuse of one-time tokens (e.g., from password resets) that may be logged.". Also, do log files have safe file permissions by default?
    – Hope4You
    Commented Aug 7, 2012 at 16:03
  • Since log files are (usually) written by the webserver that rather implies that they are readable by the webserver uid. I have to disagree with dr jimbob regarding logging POSTs - maintaining a proper audit history at the HTTP level is a requirement for activities to improve the security of a site.
    – symcbean
    Commented Aug 7, 2012 at 16:11
  • @Hope4You - Your application may have functionality similar to a user requests to reset a password, receives an email with a link like: https://www.example.com/reset_password?user=yourname&token=JslcqcUDFD5a1yEzyTckzud and once they click that link the token is checked and if its valid, the user is directed to a page where they can reset their password. The logging of the random token is only a problem if it could be re-used later; that is if I could see the log file find the token and reset it. If its a one-time token (expires after use), you don't have to worry about it being logged.
    – dr jimbob
    Commented Aug 7, 2012 at 16:23
  • @symcbean - If you have users' login via POST and you record the data contents of their POST request in a log file, you just recorded their password in plaintext that an attacker/malicious admin could use. Never record a user's password in plaintext. (And similar goes for other confidential information). Keep confidential data in the protected database with fine grained access controls, encryption, etc. There's nothing wrong with plaintext logging POSTs that don't have confidential information. Not to say you shouldn't record IP/Timestamp/URL/response code/message size/etc for POSTs.
    – dr jimbob
    Commented Aug 7, 2012 at 16:30
  • @symcbean - Also by prevent non-root users from reading; by non-root user I don't specifically mean every UID except (UID=0) I mean users who have normal accounts, have passwords and can login (e.g., have a hash in /etc/shadow) unlike www-data (or the webserver user/group). Or in a sudo setup, everyone who is not in the superuser group. Yes, the files will be read-writeable by www-data, but not readable by any unprivileged users (don't let them in www-data group). Also linux log files (the L in LAMP) like auth.log/secure.log are often owned by root or an adm/syslog group.
    – dr jimbob
    Commented Aug 7, 2012 at 16:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .