The SAMP protocol is defined in two parts, as an abstract API and as transport-specific Profiles. One or more Profiles may be offered by a SAMP hub to allow clients to communicate with it. At present, JSAMP offers two basic profiles, the Standard Profile, intended for normal desktop-based clients, and the Web Profile, intended for browser-based clients (some variants of these are also possible). These are described below.
By default, the hub is configured with both Standard and Web profiles
running.
You can turn them on and off while the hub is running using
the Profiles menu.
You can configure which profiles are run on startup using the
-profiles and -extraprofiles
hub flags or the
jsamp.hub.profiles and jsamp.hub.profiles.extra
system properties,
or if you're writing code with one of the methods in the
Hub class.
The Profiles menu in the hub window looks something like this:

and from the system tray icon something like this:

Checking one of the checkboxes has the effect of turning the profile in question on, and unchecking it turns it off. When a profile is turned off, any clients registered using that profile are forcibly ejected from the hub.
The Standard Profile is intended for use by normal desktop tools.
Clients discover the location of the hub by looking in a file named
.samp in the user's home directory.
The fact that this file is normally only readable by the user running
the hub means that connections cannot be made by other users.
The Web Profile is intended for use by web applications, that is, programs or web pages running inside a web browser. Web applications can find the hub at a well-known port. When a web application wants to register, the hub will ask the user, by popping up a dialogue window, whether the application should be allowed to run. The dialogue window will look something like this:

There are a number of configuration options available for the Web Profile
hub, connected with security.
They may be set on the
hub command line,
with the various -web:* options,
or using the Profiles|Web Profile Configuration menu.
The options are as follows:
crossdomain.xml mechanism.
This may be less secure than CORS, but is required for
some browser/web application combinations.
If you use a browser that supports CORS
(thought to be: Chrome v2.0+, Firefox v3.5+, Safari v4.0+, IE v8+),
and only use JavaScript-based web SAMP applications, you may be able
to leave this switched off and thereby improve security.
clientaccesspolicy.xml mechanism.
Silverlight is believed to support the Flash mechanism, so you can and
should probably leave this switched off.
Note that the configuration options may only be changed when the Web Profile itself is not running.
You may be able to find an experimental Web Profile client here.
The JSAMP 1.3 Proposed Recommendation discusses security in relation to the Web Profile, but notes that there remain some security concerns, and that experimentation will continue in hub implementations around this issue.
The security measures taken by the JSAMP Web Profile implementation relating to the Web Profile are:
file:///etc/passwd.
This policy is on by default, but can be switched off and on using
the Profiles|Web Profile Configuration|URL Controls menu item from
the hub GUI, or with the -web:[no]urlcontrol hub
command-line switch.
samp.app.*, table.*,
image.*, and others which are used for the normal
exchange of data. This restriction can be switched off and on using
the Profiles|Web Profile Configuration|MType Restrictions
menu item from the hub GUI, or with the
-web:[no]restrictmtypes hub command-line switch.
There are ways from both the hub and the (non-Web) client side of
achieving finer control.
In particular non-Web clients may annotate their MType subscriptions list
using the key "x-samp.mostly-harmless";
setting this to 1 or 0 adds the MType to or removes it from the whitelist
for that particular subscribing client.
See the documentation of the
ListMessageRestriction class
for more detail.
The upshot of all this is that in the default configuration, even if a hostile web application connects to the hub, it is most unlikely to be able to do anything worse than, for instance, send unwanted FITS images to your image viewer. If such a hostile client is oberved, it can be forcibly disconnected, either individually or by shutting down the Web Profile (or the Hub itself). Such a hostile (or indeed friendly) client can of course only ever connect to the Hub following explicit authorisation by the user (clicking "Yes" on the registration popup dialogue).