Badges like you mentioned are usually just blank SVG images without the information (you can take a look at the templates here).
So, for a service to create the SVG (or PNG):
- the service gets the update data from you through a CI system of some sort
- The service generates a corresponding image (either SVG or PNG) which is attached to a certain
GET
endpoint
The Service has two ways to implement this:
- Use shields.io as a service, sending a JSON with the information on how to generate the image to their JSON endpoint
- Implement the image generation internally using shields.io as a library or by any custom means.
So either way, SaaS applications that have badges usually serve them themselves (even if internally they call shields.io). This means each service can implement whatever security measures themselves.
The data that is passed to shields.io usually includes two words and some colors. So not too much information is exposed in order to generate the badges (see example below). Also, the communication between the service and shields.io is encrypted and sent over HTTPS.
For privacy, one example is that big companies usually have hosted solutions that are accessible only internally, so the badges are accessible internally only as well.
The badges specifically included in your question contains only public data from app stores or stars for a GitHub project etc. which is usually public as long as the project itself is public. Those badges very often use shields.io API to generate them automatically using the public data.
But if you'll look at badges for things like Coveralls or Travis, you'll see they host their own badges:
Here's a little typescript example on how to create a badge using the shields.io as a library and serve it:
First, install gh-badges with
npm i gh-badges --save
and this is how you use it:
import { BadgeFactory } from 'gh-badges';
(async () => {
const bf = new BadgeFactory();
const format = {
format: 'svg',
text: [ 'coverage', '90%' ],
labelColor: '#894597',
color: '#5d5d5d',
template: 'for-the-badge',
logo: [
'data:image/png;base64,iVBORw0KGgoAAAA',
'NSUhEUgAAACAAAAAgCAYAAABzenr0AAAABmJL',
'R0QA/wD/AP+gvaeTAAAA/0lEQVRYhe3WMU7DM',
'BjFcadqh0qdWWBl7QU4Ss/AjsREF8RdOhYO0E',
'qoN2DhFIgBOvBjIIMVxSFyUiEhP8lD7C/v/T9',
'7sEMoKkoIe+Npn8qpOgCM2VBVVa1ZkzFDcjQd',
'apDqLIR+u/jnO1AACkABKABdAO9DjHEWfb7lA',
'LwOAQghXPXx6gJ4zE3GJIRwE0095Zhc4PO3iz',
'7x7zoq+cB5bifr9tg0AK7xFZXcZYXXZjNs+wB',
'giofG8hazbIDaeI5dFwAu8dxY2mE+KDyCWGCT',
'YLj3c86xNliMEh5BVLjFseNEjnVN8pU0BsgSh',
'5bwA5YnC25AVFjhpR6rk3Zd9K/1Dcae2pUn6m',
'qiAAAAAElFTkSuQmCC'
].join('')
};
return bf.create(format);
})();
This is basically the same data that is sent to the shields.io as a service endpoint mentioned above.
You can see the full example in a controller context here and here.
About the risk of it, mostly think about what data is actually exposed here. It's almost nothing. and if you're worried about the data privacy, you can just generate the badges yourselves and serve them or embed them as privately as you want ;-)