BIG SECURITY HOLE in fckeditor

no.
that's a BIG SECURITY HOLE in your application.

A malicious user won't waste his time inserting the data into the editor, instead he will post it directly bypassing any client-side checks, so if you just accept any data that it's sent and then use it without performing any sanity check then you're toast.

Implement a filter at your server side ASAP.

Protecting the code at the client side only brings a false sense of security. There are many more ways to inject code than using <script> tags.
You can search for previous threads about this kind of issues or google about them, I think that HTMLPurifier was one of the scripts that takes care of them.
You must remember that it's quite easy to do a proper cleanup as the output of FCKeditor is a valid XML tree, you you can easily manipulate and remove any attributes/nodes that you don't want and then recreate a new string that it is safe. You don't need to do anything at the client side.

While alfonsoml is correct that any server accepting html input must prevent malicious code, I think that it would be a valuable service if fckeditor did the work to prevent code in its html output. As a server side developer, I want to know when a user is being malicious. As it stands now, when accepting data from an fckeditor control, I can not write code to distinguish between a malicious user and a user that just happened to copy & paste malicious html. If the fckeditor control did the filtering to prevent malicious html in its output, then whenever the server received malicious html we would know it is a malicious attacker and can respond accordingly.

Relying on FCK to prevent malicious code is about as practical as expecting a textarea element to do the same as part of a future HTML standard. FCK is a RTE. As such, it should be regarded as a glorified form element with the responsibility of filtering scripts and the like squarely on the application within which FCK resides. If a later version of FCK attempts to prevent malicious code I won't rely on it.

Let me give you an analogy. A form has a select input with two choices "foo" and "bar". If our server receives a post for that form with another value for that control, it knows that somebody is trying to hack into the system. In such a case, it does no further processing of the request; instead, it just logs the incident and return a generic server error (for we want to give the hacker no information as to why the post failed). Our IT staff is trained to investigate such incidents and disables the accounts of any hackers (the other possibility is that we have a bug in the application where it generated a select option that the action handler did not recognize).

If fckeditor had the ability to filter html being pasted into its control such that it could filter out embedded code, then when the server received data -- from that control -- that had such embedded code, it would know that somebody circumvented the control (or that there is a bug in the control's filtering). In either case, the server would stop processing the request and log the incident.

Notice that in both scenarios above, the server does not "rely" on the control. But it can take advantage of the control's expected behavior to detect hackers. Because the fckeditor does not have any such filtering, servers using the control has one of two choices:

1. Assume that any embedded code in the html is coming from a hacker and stop processing, or
2. Filter out the embedded code and continue processing.

Going with choice 1 is unfriendly to the innocent user who unintentionally copied & pasted from a web page with embedded code. Going with choice 2 would allow a hacker to use trial and error to find a weakness in your server's filtering. Obviously, you can log requests that contain embedded code when using choice 2, but it takes time for IT to investigate any given incident and such an investigation isn't as straight forward when the IT person has to distinguish between "innocent" and "malicious" instances.

In our shop we will probably go with choice 1. If we see that we get a lot of server errors due to "innocent users," we will probably implement filtering in fckeditor to minimize such errors. Note that any such filtering in fckeditor will just be a bonus. We will never "rely" on it.

The problem about implementing such protection at the editor level is that (besides the time that it's needed, time that can't be used to work in other parts) everyone has different needs.
Some might want to disable all scripting. Other people might have other requirements, so the first task would be to define how to do a proper validation.
Then you have to apply that validation, I think that I would add it at the xml-> text serialization, but it might depend on the rules that you want to apply.

And for me, the problem if some simple javascript validation is added, is that too many people would think that it's enough. I've seen too many people that despite the warnings in the server connectors to apply some kind of session validation, they just leave them enabled for everyone because it's easier that way, so I won't trust them to use another extra code to prevent XSS attacks, they will think that the default one is good enough.

Anyway, you should go ahead, look at what you need, how it's done for example in the purifier mentioned previously and if you share your code other people might contribute to it.
Specially in the new CKEditor the core will be minimal, so almost everything is a plugin.