<!--
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
-->

<p>About security for <span class="weinre">weinre</span>: <b>there is none</b>.

<p>Obviously there should be some.  The question is, what do we need to do?

<!-- ======================================================== -->
<h2>Background and potential exposures</h2>

<p>Currently <span class="weinre">weinre</span> uses plain old HTTP - not HTTPS - and provides
no level of authentication for requests.

<p>The primary security exposure with <span class="weinre">weinre</span> is via
the debug server.

<p>Currently, the server only reads files from the weinre-node distribution,
and from the <tt>~/.weinre/</tt> directory (for property files).
The only thing the server writes to is <tt>stdout</tt> and <tt>stderr</tt>.

<p>If you use the default <tt>--boundHost</tt> option value of
<tt>localhost</tt>, then any software on the machine running the debug
server can communicate with the debug server.  This probably isn't a big
deal, since presumably you control the software running on that machine.

<p>If you use a non-default <tt>--boundHost</tt> option value,
then <b>any software on any machine that can access that specified
host can communicate with the debug server</b>.  This is a much bigger
deal.

<p>The most obvious exposure with using <tt>--boundHost</tt> and
a specific hostname / ip address, is that any debug client or
debug target that can access that hostname / ip address can access
the server.  For example, a rogue debug client could connect to
your debug target and fiddle about with it.

<p>Other exposures include leaving a debug target injection
script line (ie, <tt>&lt;script src="[...]/target/target-script.js"&gt;</tt>)
in your web page, and then that web page connects to a rogue debug
server running at that address.

<!-- ======================================================== -->
<h2>Future Implementation Ideas</h2>

<ul class="spaced">

<li>Let's chat

</ul>