Cross-frame scripting is not a term I've seen used before. From what I've read, it sounds like it's a subset of XSS (Cross-site scripting) using injected frames. Blocking cross-site scripting should be the top priority. The critical behaviors to protect against XSS are output encoding (anything that could possibly be user-controlled gets escaped or entity-encoded before being echoed into the response, for example, a
< sign into an HTML context should be turned into
<) and input validation (don't let users put any kinds of values that don't match the expected format and characters for each field).
If you want a header-based protection against XSS, the solution is Content Security Policy, which restricts the sources of all kinds of potentially-malicious content (usually focused on scripts and stylesheets, but it also supports restricting frames). Used properly, CSP is an extremely strong protection, but users running old browsers (including all versions of IE) won't be protected by it (though Microsoft Edge supports it, or will soon, I forget). Note that using CSP correctly may require some refactoring of your site, to move all scripts, etc. to their own files instead of allowing inline script.
For protection against your site being framed by an attacker, the
X-Frame-Options header is your go-to solution, protecting everything except extremely old browsers (like, IE6). Generally speaking, use
DENY instead of
SAMEORIGIN unless you have some specific reason to use
SAMEORIGIN; it's not really an additional security boundary per se, but it can make certain types of attacks harder.