When a Slave is read-only, it is not 100% shielded from the world.
According to MySQL Documentation on
This variable is off by default. When it is enabled, the server permits no updates except from users that have the SUPER privilege or (on a slave server) from updates performed by slave threads. In replication setups, it can be useful to enable read_only on slave servers to ensure that slaves accept updates only from the master server and not from clients.
Thus, anyone with SUPER privilege can read and write at will to such a Slave...
Make sure all non-privileged users do not have the SUPER Privilege.
If you want to revoke all SUPER privileges in one shot, please run this on Master and Slave:
UPDATE mysql.user SET super_priv='N' WHERE user<>'root';
With reference to the Slave, this will reserve SUPER privilege to just
root and prevent non-privileged from doing writes they would otherwise be restricted from.
UPDATE 2015-08-28 17:39 EDT
I just learned recently that MySQL 5.7 will introduce super_read_only.
This will stop SUPER users in their tracks because the 5.7 Docs say
If the read_only system variable is enabled, the server permits client updates only from users who have the SUPER privilege. If the super_read_only system variable is also enabled, the server prohibits client updates even from users who have SUPER. See the description of the read_only system variable for a description of read-only mode and information about how read_only and super_read_only interact.
Changes to super_read_only on a master server are not replicated to slave servers. The value can be set on a slave server independent of the setting on the master.
super_read_only was added in MySQL 5.7.8.