# Opera Widgets security model

Opera Widgets can download and combine data from most parts of the web, which make them a powerful platform for delivering innovative services to users. The security model is initially very open to allow authors to easily create such services. The widget author may change the `config.xml` file of the widget in order to restrict the widget’s access to protocols, hosts and ports.

## The initial security model

If nothing is specified in the widget’s `config.xml` file, the following applies.

- A widget can contact any host over the http:// protocol.
- A widget cannot contact protocols other than http://, unless specified in its config.xml.
- A widget cannot access the file system using the file:// protocol.
- A widget cannot contact non-standard ports (0–1023, except 80), unless specified in its config.xml.
- A widget cannot make use of Java applets or plugins.

Note also that many browsers block outgoing HTTP requests on port 443, as this is reserved for HTTPS. Defining access to this port and protocol combination will not work.

### Either internet or intranet access

A special limitation is that widgets may only contact either internet addresses or intranet addresses, not both kinds. If the widget contacts an internet address, it may not subsequently make a connection to an intranet address, and vice versa. This includes fetching images, CSS files and other resources, as well as making Ajax calls.

The following IPv4 IP ranges are defined as intranets:

- 10.0.0.0 to 10.255.255.255
- 172.16.0.0 to 172.31.255.255
- 192.168.0.0 to 192.168.255.255
- 169.254.0.0 to 169.254.255.255

## Controlling the widget’s security

You can use the widget’s `config.xml` file to limit its access to only specific domains, ports and protocols. The `<security>` element is used for this purpose.

Each `<security>` element may contain a series of `<access>` elements, which specify what the widget can access. The `access` element can contain the following elements:

protocol
  This specifies the protocols the widget will be using to contact external servers. All protocols except the file:// protocol are permitted.
host
  The `host` element establishes which hostnames may be contacted. The hostnames are exact matches. This means that a widget specifying www.example.com must not be able to contact example.com. IP addresses may also be used as values.
port
  The `port` element establishes which port numbers the widget will be using. The value is either a number, a range of numbers separated by a dash, eg 1024–2048, or a comma-separated list of ports, e.g. 80, 1337.
path
  The `path` element specifies the path part of the URI that a widget may contact.

If any of the child elements of the `access` element are missing, a value meaning ‘all’ is assumed. For the protocol, http:// is always available, regardless of which protocols are specified in an `access` element. There is currently no way to remove all network access for the widget.

### Plugin and Java access

The widget may initially not make use of Java applets or plugins for its content. This can be activated by including a `content` element as a child of the `security` element. The element has two attributes, `java` and `plugin`, which can have a value of ‘yes’ or ‘no’.

## Examples

Let’s look at a few examples of how the security model and the `access` element interact:

    <security>
      <access>
        <protocol>http</protocol>
        <protocol>https</protocol>
        <host>example.com</host>
        <host>example.org</host>
        <path>/good</path>
        <port>2048-4906</port>
        <port>80,1337</port>
      </access>
      <content java="yes" plugins="no" />
    </security>

In this example, the widget is limited to contacting the hosts example.com and example.org, using either the http:// or https:// protocols. It may only contact those hosts on ports ranging from 2048 to 4906, and the ports 80 and 1337. The widget may only access the path ”/good” on both hosts. The widget may make use of Java applets, but may not use other plugins.

Let’s look at another one:

    <security>
      <access>
        <host>example.com</host>
        <port>2048-4906</port>
      </access>
      <access>
        <protocol>https</protocol>
        <host>example.org</host>
        <port>80,1337</port>
      </access>
    </security>

In this example, there are two primary rules. The widget’s access is limited to example.com and example.org. The widget may only access example.com over the http:// protocol and on the ports 2048 through 4906. example.org can only be accessed over https:// and the ports 80 and 1337. In both cases the widget may access any path. The widget may not make use of Java applets or plugins, which is the default.

    <security>
      <access>
        <host>example.com</host>
        <port>2048-4906</port>
      </access>
    </security>

In this last example, the widget may only contact example.com over http://, on any port in the 2048–4906 range, using any path.

## Resources

- Opera Widgets Specification 1.0, third edtion
- Opera Widgets can connect to multiple web servers