Does your software poll this input, or do you use an interrupt scheme to process it?
If you're polling, presumably you read the input at a much higher rate than the expected changes in the signal. If the noise is well separated, very high frequency spikes, these would then look like isolated samples of the 'wrong' polarity. You could mitigate this by keeping the most recent N samples and deciding to read the input as whichever polarity is in the majority. I.e., if N=5, then if you have 3, 4 or 5 '1' bits, your input is a '1'; if you have 0, 1, or 2 '1' bits, your input is a '0'. This is really just a sort of low-pass filter in software.
If you are using the input to trigger interrupts on change (both edges), you can have the interrupt routine (ISR) start a timer to cause a second interrupt a short time later, but longer than the noise spike time. Rather than have the input pin ISR directly accumulate signal bits, you have the timer ISR do it. For example, if the signal is low, and a high spike comes along, the rising edge start the timer, but before the timer count expires, the falling edge of the spike resets it, so when the timer interrupt finally does go off, you're looking at the signal, not the noise. The signal, on the other hand, will kick off the timer just once, and the timer ISR will be able to grab the new signal level.
Of these two, Polled vs Interrupt, personally I'd go for the polled approach, b/c (1) interrupts are just more complicated, and (2) a pathologically placed pair of spikes could still give you false input.