Error "Public files directory Not fully protected" Appears in Nginx? I'm wondering why this errors appear on my drupal site when I am using Nginx:

Public files directory  Not fully protected
See http://drupal.org/SA-CORE-2013-003 for information about the recommended .htaccess file which should be added to the sites/default/files directory to help protect against arbitrary code execution.
Error
Temporary files directory   Not fully protected
See http://drupal.org/SA-CORE-2013-003 for information about the recommended .htaccess file which should be added to the tmp directory to help protect against arbitrary code execution.


Any solution to this?
In the security advisory referenced in the error, it describes the specific vulnerability as "Code execution prevention (Files directory .htaccess for Apache - Drupal 6 and 7)" and recommends updates to your htaccess files in your files directory. Part of the recommended htaccess update is the following text:

# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
&lt;Files *&gt;
  # Override the handler again if we're run later in the evaluation list.
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
&lt;/files&gt;


The SetHandler string is what Drupal is using to determine whether you've made this change or not.  Even though you're using Nginx as your webserver, its still going to display this error until you've made this update. From the advisory again: 


  To fix the code execution prevention vulnerability on existing Apache
  installations also requires changes to your site's .htaccess files in
  the files directories. Until you do this, your site's status report
  page at admin/reports/status will display error messages about the
  problem. Please note that if you are using a different web server such
  as Nginx the .htaccess files have no effect and you need to configure
  PHP execution protection yourself in the respective server
  configuration files.


I'm running a couple nginx servers as well and had to make these updates just to make these errors go away. I was curious how they were doing this check and found this in the 
modules/system/system.install file at line 284:

// Check for the string which was added to the recommended .htaccess file
// in the latest security update.
if (!file_exists($htaccess_file) || !($contents = @file_get_contents($htaccess_file)) 
|| strpos($contents, 'Drupal_Security_Do_Not_Remove_See_SA_2013_003') === FALSE) {
...