Is it possible to prevent injection of external resources and requisitions for greater security?


I understand that we can create and search javascript plugins, parse the code and make sure it will not inject anything into the page out.

But supposing there is some library to inject elements <script> , <link> , <img> , <video> , <audio> , ...

This can cause the following problems:

  • Open security holes such as injecting "malicious" scripts
  • Capture by referer source page
  • Affect performance
  • Is it possible to prevent a script from inject with document.createElement (or innerHTML or document.write ) elements that access external resources?

    Or is it possible resources that come from outside the allowed domains?

    For example, prevent requests from external servers:

    Prevent Injection of .js Files

    var inject = document.createElement("script");
    inject.src = "//";

    Prevent Injection of Image Files and .css

    Images, videos, and other similar resources can catch the referer of the source page and in case I want to prevent this to prevent them from knowing the source page, since it can be a restricted url:

    var inject = document.createElement("img");
    inject.src = "//";
    var inject = document.createElement("link");
    inject.rel = "stylesheet";
    inject.type = "text/css";
    inject.src = "//";

    And as quoted the

    var inject = document.createElement("img");
    inject.src = "//" + document.cookie;
    asked by anonymous 18.07.2015 / 19:39

    2 answers


    Through the headers you can configure the CSP (Content Security Policy) and it is possible to block external requests and even other security issues.

    CSP header example:

    This header will allow requests from the same domain, will prevent inline scripts and the use of eval :

    Content-Security-Policy: default-src 'self'

    This header will allow requests from the same domain, will prevent eval , but will allow inline scripts:

    Content-Security-Policy: default-src 'self' 'unsafe-inline'


    • 'none'

      Refers to the empty definition; that is, that

    • 'self'

      Refers to the source from which the protected document is being called, including the same URL scheme and port number. Some browsers specifically exclude "blob" and "file system" from source directives. Sites that need to allow these content types can specify them using the data attribute.

    • 'unsafe-inline'

      Allows the use of inline resources such as <script>alert(1);</script> or <style>a {}</style> and javascript: in events (for example <a href="javascript:alert(1);"> )

    • 'unsafe-eval'

      Allows the use of the eval function

    Allow blob and access to system files

    Many systems require the use of dynamic urls to upload and create, but default-src 'self' can prevent this, so use:

    Content-Security-Policy: default-src 'self'; img-src 'self' data: blob: filesystem:; media-src mediastream:

    Source: link


    To use this with PHP you need to use header :

    header('Content-Security-Policy: default-src \'self\'');

    Apache and .htaccess

    To use Apache, you can use httpd.conf or .htaccess and mod_headers :

    <IfModule mod_headers.c>
        Header set Content-Security-Policy "default-src 'self'"


    On IIS servers

    <set name="CONTENT_SECURITY_POLICY" value="default-src 'self'">


    With c # you can access HttpContext and set it to a variable called context:

    HttpResponse HS = context.Response;
    HS.AddHeader("Content-Security-Policy", "default-src 'self'");


    With Django:

    def main(request):
        response = HttpResponse()
        reponse["Content-Security-Policy"] = "default-src 'self'"

    With Flask (in this case define in route / ):

    def home():
        resp = flask.Response("foo")
        resp.headers['Content-Security-Policy'] = 'default-src \'self\''
        return resp
    18.07.2015 / 22:35

    Update: modern browsers implement Content Security Policy (CSP), which allows sites to target the browser in the sense of allowing / blocking various things. More details on Guilherme Nascimento's answer .

    With pure JavaScript, no. It is possible to restrict something from scripts by setting them to iframe with the sandbox attribute, but this fine level of control is more difficult.

    If you have a script - external or not - and you want to ensure that it only does what you explicitly allow, you need to modify it to get to that end. At first this could be done in the browser , but then you would need a parser JavaScript in JavaScript (which is feasible but not very efficient). Another option is to do this on a server. The google-box project is just the right thing to do.

    I have never used it, so I can not state its effectiveness, but the idea is to provide a capability-based security model so that the script does not have access to the global object and all your classes / functions, but only what you make available to it.

    (Note: In some circumstances, JavaScript code contained in a function can be executed in strict in>> so that it also does not access the global object, but I would not rely on that to ensure site security.)

    This answer in security.SE lists some other tools that may help with this purpose.     

    18.07.2015 / 20:05