Answers.Body: <p>It depends on what kind of secure infos you write into your templates. I wouldn't put my credit card infos into a twig comment for example, if the template is not above the root.</p>
  
  <p>But normally all one could make up from the raw template code is rather uninteresting and not really relevant for further hacking attempts, I'd say.</p>
  
  <p>Note: please do <strong>NOT</strong> put the <code>craft/config/</code> folder above the root!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-29T20:03:44.530Z
Answers.Text: Agree with carlcs, but to be safe, I'd add a .htaccess which denies direct user access
Answers.UserDisplayName: Victor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-29T14:47:02.377Z
Answers.LastActivityDate: 2014-07-29T14:55:13.547Z
Answers.LastEditDate: 2014-07-29T14:55:13.547Z
Answers.UserDisplayName: carlcs
Answers.Body: <p>If you’re running Apache, you can put a .htaccess file in your templates/ folder with this in it:</p>
  
  <pre><code>Deny from all
  </code></pre>
  
  <p>and any HTTP traffic to that folder will be given an Apache 403 error.</p>
  
  <p>Even better, you can put this in there:</p>
  
  <pre><code># Send the request to Craft
  RewriteEngine On
  RewriteRule (.*) /index.php?p=$1 [QSA,L]
  </code></pre>
  
  <p>and the request will be redirected to Craft’s index.php file behind the scenes, the same way that would-be 404s are sent there. So even if you go to /templates/index.html, or any other URL that points to an actual file within your templates/ folder, it will end up as /index.php?p=templates/index.html, leaving Craft to handle the request, which will most likely result in a Craft-based 404.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-29T19:53:28.350Z
Answers.LastActivityDate: 2014-07-29T19:53:28.350Z
Answers.UserDisplayName: Brandon Kelly
Body: <p>Due to the way our build and deployment process works, it's convenient for us to have the Craft templates inside our /public/assets folder together with our css and javascript, instead of in /craft. Does this make the site less secure than having them outside of the public root?</p>
  
Tags: <templating><security>
Title: Is it a security risk to put Craft templates inside public root?
ThreadText: # Is it a security risk to put Craft templates inside public root?
  
  (Asked by: username_0 on 2014-07-29)
  
  Due to the way our build and deployment process works, it's convenient for us to have the Craft templates inside our /public/assets folder together with our css and javascript, instead of in /craft. Does this make the site less secure than having them outside of the public root?
  
  **Tags:** templating, security
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2014-07-29. Score: 7 | Accepted answer
  
  If you’re running Apache, you can put a .htaccess file in your templates/ folder with this in it:
  
  ```
  Deny from all
  
  ```
  
  and any HTTP traffic to that folder will be given an Apache 403 error.
  
  Even better, you can put this in there:
  
  ```
  # Send the request to Craft
  RewriteEngine On
  RewriteRule (.*) /index.php?p=$1 [QSA,L]
  
  ```
  
  and the request will be redirected to Craft’s index.php file behind the scenes, the same way that would-be 404s are sent there. So even if you go to /templates/index.html, or any other URL that points to an actual file within your templates/ folder, it will end up as /index.php?p=templates/index.html, leaving Craft to handle the request, which will most likely result in a Craft-based 404.
  
  
  ---
  
  ### Answer by username_1 on 2014-07-29. Score: 3
  
  It depends on what kind of secure infos you write into your templates. I wouldn't put my credit card infos into a twig comment for example, if the template is not above the root.
  
  But normally all one could make up from the raw template code is rather uninteresting and not really relevant for further hacking attempts, I'd say.
  
  Note: please do **NOT** put the `craft/config/` folder above the root!
  
  > **Comments:**
  > **username_2**: Agree with username_1, but to be safe, I'd add a .htaccess which denies direct user access  
  
  ---
  
  