# Blade templates directly accessible via web browser on server

**URL:** https://discourse.roots.io/t/blade-templates-directly-accessible-via-web-browser-on-server/15059
**Category:** sage
**Tags:** sage9, blade
**Created:** 2019-03-14T00:57:25Z
**Posts:** 9

## Post 1 by @pkarjala — 2019-03-14T00:57:25Z

While testing our application, we noticed that we were able to get directly at the raw blade templates by going to `https://our.server.com/wp-content/themes/theme-name/resources/views/template-for-page.blade.php`. This is possible because we know the directory structure and can browse directly to view the files, so the likelihood of an end user hitting this is fairly slim. However, it still directly exposes template code to the world.

Is this permitted by Sage 9 by default? Is there a configuration option within Sage 9 that prevents this access? Or should we be relying on `.htaccess` files or other web server methods to hide direct access to this directory?

---

## Post 2 by @Log1x — 2019-03-14T02:22:46Z

Nice find. Never thought about it since I’m used to Laravel not having it’s views in the `public` folder– in this case, it might be a little more tricky.

Deploying a fix in Trellis for example would be trivial, but to do it widespread…I’m not so sure yet.

In the mean time, yeah– if you are worried about it, just handle it with `.htaccess` if you are using Apache.

`deny from all` inside of your `resources/views/.htaccess` _should_ do the trick.

If you are using nginx, you can do this with:

```
location ~* \.(blade.php)$ {
    deny all;
    access_log off;
    log_not_found off;
}
```

**Edit:** I’ve pushed a fix to Trellis as seen [here](https://github.com/roots/trellis/pull/1075). Since server-side is the only way to prevent access

Sage docs also now show how to [secure Blade templates](https://roots.io/sage/docs/deployment/#server-configuration)

---

## Post 3 by @joshf — 2019-03-14T14:11:50Z

This snippet should address the issue in Apache 2.2 and 2.4:

```
<FilesMatch ".+\.(blade\.php)$">
    <IfModule mod_authz_core.c>
        # Apache 2.4
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        # Apache 2.2
        Order deny,allow
        Deny from all
    </IfModule>
</FilesMatch>
```

---

## Post 4 by @bikubi — 2019-03-15T14:05:55Z

And what about `/vendor/`? Aside from Trellis, is it recommended to `Deny all` there, too? I assume that it is probably safe not to do so, but since there’s a gazillion files & packages, you can never be 100% sure, right? And since it is all `include`d it should not have any downsides, right? Or am I missing something? It kinda does feel like a stupid question :smiley:

---

## Post 5 by @Log1x — 2019-03-17T03:11:00Z

Wouldn’t worry about vendor. Most libs (esp. ones that are stock with Sage) will result in a blank file if accessed directly. The reason the Blade templates are more evasive is due to it showing unwarranted source code of your theme in plain text.

---

## Post 6 by @bikubi — 2019-03-19T15:14:48Z

ah, of course!  
I was curious and checked the outputs like this:

```
for i in $(find vendor/ -name '*.php'); do
  url="$(jq -r '.devUrl + .publicPath' resources/assets/config.json)/$i";
  echo $url;
  curl $url;
done
```

non-empty outputs:

```
vendor/symfony/process/Tests/NonStopableProcess.php
received vendor/symfony/process/Tests/ProcessBuilderTest.php

vendor/symfony/process/Tests/SignalListener.php
Caught vendor/symfony/process/Process.php

vendor/symfony/translation/Tests/fixtures/extractor/translation.html.php
This template is used for translation message extraction tests

vendor/squizlabs/php_codesniffer/scripts/build-phar.php
Building phpcs phar
	=> REDACTED/vendor/squizlabs/php_codesniffer/scripts/phpcs.phar
	=> adding files from package.xml... Unable to load package file:
```

Not sure, but the scripts… look benign :slight_smile:

---

## Post 7 by @thomasfw — 2019-03-19T21:18:50Z

I’ve gone with adding the usual `<?php defined('ABSPATH') or die(); ?>` to the top of my blade templates in the past.

Anyone aware of any issues arising from the use of php tags in the template file (other than it being ugly)? All seems to function as expected in my experience.

---

## Post 8 by @alwaysblank — 2019-03-20T00:04:43Z

> [@thomasfw](#):
>
> Anyone aware of any issues arising from the use of php tags in the template file (other than it being ugly)?

Blades get compiled to actual PHP, so it shouldn’t cause any problems (unless you have blade or blade-y stuff inside your PHP tags, and then it…might do something?).

---

## Post 9 by @system — 2019-04-25T00:57:27Z

This topic was automatically closed after 42 days. New replies are no longer allowed.