For the record, this effect is called texture bleeding so if you don't like my answer, search that and you'll get thousands of solutions.
Firstly, I just want to check that you aren't using mipmapping. You're are in 2D so it doesn't make any sense to, but some people do out of force of habit or just because they haven't thought it through (which is understandable). As I've said I just add a border and be done with it, but the best solution I've heard of, off the top of my head, is half pixel correction.
Normally your tex coords are actually on the border between to pixels. Imagine a 100 pixel wide (1D for simplicity) texture. You sprite starts at the 7th pixel, so your tex coord is 0.07 right? But that position is actually the start of the 7th pixel which in reality is the border between the 6th and 7th pixel. So when OpenGL wants to sample at 0.07, it blends the 6th and 7th pixels together. The solution is to set the tex coord to the centre of the 7th pixel rather than the start. So 7.5 / 100 = 0.075. So a general formula for the nth pixel in an w wide texture (still 1D) is (n + 0.5) / w, right?
But what if the end of you sprite is the 19th pixel, then (19 + 0.5) / 100 is 0.195. Except that is the centre of the 20th pixel. It should be (19 - 0.5) / 100 is 0.185. So you see the problem with this method. When you work out the tex coords (this is mainly a problem for dynamic texture atlases), you need to know where in the sprite that tex coord comes from. Not a massive problem, just watch out for it.