Warcraft 3 maps should be protected, in the same way that Warcraft 3 models are protected. To understand the protections, become familiar with your local and national government and its rules for intellectual property, copyright, trademark, and ownership of human authored digital content. The way to protect your content is a license. If your government does not support licenses, then your content is not protected.
Some people believe that Warcraft 3 maps can be "protected" in a way different from Warcraft 3 models. Adherents to this (in my opinion false) ideology use this term "protected" to refer to corrupting some portions of the map data -- but not all of it -- so that the map fails to open in Warcraft III World Editor. This suffers from the obvious problem of assuming that:

• Your adversary is only capable of editing Warcraft 3 maps using the official World Editor program
  
• The official World Editor program will never receive an update to be able to open a wider range of map formats without crashing
  
• Your adversary has insufficient time or mental energy to regenerate the missing or corrupted portions of the map

These are essentially all baseless, extremely flawed axioms. The first two are obviously proven false, and the third one is false for the kind of trolls that you would want to protect against in the first place. Assuming that you are a good-natured human being playing a video game with friends, who has no interest in hacking other peoples' maps against their will (and against intellectual property law, if applicable), it is then reasonable to assume that you have LESS time available than the vicious, no-lifer internet trolls who want to modify your map -- not more.

In the mid 2010s, I created a program that I only shared with a select group of people. This program was called "AssetRipper" and was capable of deep-analyzing Warcraft III maps and spawning a GUI that looked visually similar to the World Editor unit chooser dialog, which would extract out any relevant icons, models, textures, or other graphics utilized by the units selected -- even if the map loaded in the tool had no listfile. I'm not exactly clear on the exact timeline, but I believe that after I created this tool and shared it with a select group of people, one of those people was fascinated by the tool's capability to rip assets out of Warcraft 3 custom content that he said no other tool he had ever seen could do, and he used it to rip assets out of a very popular Chinese mod for the Warcraft III game, incorporated those assets into his own mod without the original author permission, utilized his own mod on his resume, was hired by then-Activision-Blizzard, and created the Reforged that we know and love today. It's possible that the timeline I have espoused here is a slight exaggeration and the events are slightly out of order versus how I presented them, but not by much. Is it possible that Reforged would be better if I had not created and provisioned that tool to those humans at that time? I do not know. I will never know. Do not be disingenuous. Do not steal the work of others without their permission.
That being said, I have spent an extraordinary amount of time to produce a game engine toy system that approximates the Warcraft 3 experience on the external LibGDX game engine -- including loading the original Warcraft 3 custom maps as-is, and attempting to play them. Picture, if you will, a future where every human being who plays Warcraft 3 also has the code for the game and can modify the game itself in any way. It is already the case that in Single Player, there is not any mechanism to disable cheat codes on Warcraft III. Suppose you make a game map so precise, so elegantly and perfectly balanced, that you believe it is your God-given right to prevent any human being from cheating on your Warcraft 3 map. And suppose that to this end, you corrupt the map in every way that you can find to damage World Editor access, and then you develop a trigger in the map which queries the game every 1 second to monitor the player gold, and exits the game with a "Cheaters are losers!" defeat popup any time that the player gold changes more quickly than a designated rate. You think you have defeated your adversary technologically beyond any reasonable doubt.
However, on my rewrite of Warcraft 3 that operates in my own way, where I can change any line of code, all it takes me to play your map is to edit the JASS function used by triggers to query the gold that a player has, and to make it return a flat value on your map. Or, if your map needs that function, I can just edit the "Defeat" function used by the triggers so that it does nothing, until I finish playing your map. Quickly you will see that if I can edit the entire game, then if I am sufficiently dedicated, in the end I always win over you in the technology arms race.
You could solve this with a gentleman's agreement. You could label your map, "Do not play this map on Retera's rewrite of the Warcraft 3 game called Warsmash, as this will ruin the experience and is against my wishes."
But that doesn't actually solve the problem, because it turns out that Warcraft 3 is already extremely modifiable. There is a file in the game storage called "Scripts\Blizzard.j" which defines triggers in the exact same format as the Trigger Editor used in the Map Editor, but the triggers it defines are automatically loaded on every map session. This means that on the original Warcraft III -- not even a rewrite -- it is already possible to introduce custom triggers into the game that apply to all play sessions, which then inadvertently apply to the map that you created and shared. So, for example, in the aforementioned case I might have to be slightly craftier -- it's pretty tough to change the behavior of the "Defeat" or "GetPlayerState(..., PLAYER_STATE_GOLD)" functions from there -- but I could instead make a trigger which fires every 1 second on a timer and sets my gold to a flat value. That way, anytime I spend gold, it jumps back up to where it was and your rate-of-change detector never fires, so I get infinite gold.
This trigger injection paradigm can be done to the game install itself for single player maps, and it's essentially impossible to stop it. Microsoft might make an upgrade for Warcraft III in the future that disables support for third party game mods, essentially trying to make it impossible that players would launch a version of the game where the available assets and scripts are anything other than the official ones -- but if they do that, they will lose a lot of players and those who remain will find more advanced ways to overtake Microsoft's code and do it anyway. We know this is true because they have already done it for World of Warcraft, where it is substantially harder and more difficult to accomplish -- and they did it anyway. So you're not going to stop the game from changing out from under you. Your best bet is to assume that multiplayer desyncs will prevent players from changing their game installs, and that means the only place you might fight this style of cheating is in a multiplayer game.
But it turns out that injecting an override file to "Scripts\Blizzard.j" or something similar can also be done to the map itself. The map is an archive, like a ZIP file, and even if I cannot be bothered to navigate your map scripts or how they work, I can still dump my own "Scripts\Blizzard.j" into your map archive. One obvious way that you might try to prevent this is by utilizing the fact that the map archive format is not exactly the same as a ZIP file, and is instead more convoluted. It is a hashtable, which is a computer science concept that you can research if that entertains you, but what it means is that:

• A one-way function is used on a filepath, such as "Scripts\Blizzard.j," for the game to determine if it is in the map archive
  
• This one-way function still works even if the text "Scripts\Blizzard.j" appears nowhere in the archive (instead only its numeric bin being present)
  
• The map can run out of numeric bins within which to place files, such that attempts to add more structurally fail by design

This means that in the worst case, when I try to toss my "Scripts\Blizzard.j" file into your map and then play it with cheats with my friends on the internet, any program that I use to inject that file will fail by design. It might tell me that the hashtable is full, or it might fail without any meaningful error placed onscreen.
That has not made it impossible to edit the map -- it has simply moved the goalpost. In this case, if I want to add a file to the map, then I may need to reconstitute the map by taking all of the files out of it, recording their exact file paths, and then building a new table with a larger table size (more bins) and then putting the files back in. This has to be possible, because the Warcraft III game has to be able to load the files from their bins in order to play the game, even if the original names of the files associated with those bins has been lost.
So, again, if I have a rewrite of the Warcraft 3 game where I can change anything, all I need to do is play your map once through with a file tracer enabled -- so every time a file in your map is loaded into the game, it also saves that file in a folder on my hard drive. This is trivially easy to develop. Before I had an open source rewrite of the game, in the mid 2010s, I developed a tool that had no visual GUI of the game and was not the full game, but which utilizes the knowledge of how the game functions to load all of the necessary units and Object Editor data from the map, parse all of their parameters, and then load all of the files associated with their parameters. In some instances it had a few bugs, but they were always solvable by improving the extent to which the tool parsed the unit data in the same style as the Warcraft III game. And all of this operated accurately and without the archive having any "listfile," because on principle the Warcraft 3 game starts from certain unit data file paths, loads those, and then expands outward to load the files designated by those -- and so this works even if you only have the numerically indexed bins in the map file and no file paths ostensibly present.

Somewhere there is an internet troll named Snarklord who thinks he has enough Snark that he has outsmarted everything I just said, by finding bugs in the Warcraft III map archive format that allow him to hide multiple datas in one bin so that the fan programs load the wrong data per a bin versus the Warcraft III game, so that an attempt to do what I described above would fail, and he thinks he has outmatched me in the technological arms race. However, Snarklord is trivially defeated by Claude Fable because at this point these LLMs are getting so smart I could just ask them to figure out what's the code difference between the original game's archive parser, and my archive parser, and then update mine to match.

So now we have presented a logical proof that no matter what you do, I can play your map online with friends with injected cheats in that map, unilaterally. But for some people, that's not good enough. Some people want more than cheats. They want to open the map in World Editor as if they were the original author. Consider, for example, the following tutorial that I wrote today on Hive to tell someone how to "protect" a map:

To that end, here are my suggestions:

• Remove the [icode].wtg[/icode] file that defines trigger information, so that all the triggers are missing when opening the map in World Editor. Also delete the .wct file.
  
• Change the name of all of your variables in your map script file to [icode]a[/icode] and [icode]aa[/icode] and [icode]ab[/icode] and [icode]xyz[/icode] and other short random combinations of letters that make anyone trying to read your code very mad and demoralized.
  
• Use the Lua programming language instead of Jass. Per your question, I believe this is known to introduce possible desyncs and crashes unless you are much more careful. However, the language is already syntactically harder to read than Jass and if you change all your variable names to [icode]a[/icode] and [icode]aa[/icode] and [icode]ab[/icode] per my previous instruction, the probability that any human reading your code will become so cross that he will stop trying increases.
  
• Delete the file [icode]war3mapUnits.doo[/icode] from the map, erasing World Editor data regarding the locations of units. This way, unit locations will only live on in map script but the World Editor won't know how to load that.
  
• Move the [icode]war3map.j[/icode] and [icode]war3map.lua[/icode] script files into a subdirectory that the game happens to still load. I seem to recall [icode]Scripts\war3map.j[/icode] was supported but depending on whether your map uses the Custom Data setting, or the HD graphics, you might even be able to get away with [icode]war3.w3mod\_balance\custom_v1.w3mod\scripts[/icode] or something. It's been a while since I tested this but you might enjoy poking around so that you know you've learned something nobody else knows anyway, which is kind of the entire point.
  
• Instead of having your custom units defined in the standard [icode]war3map.w3u[/icode] changeset file, which is the format usually saved by the World Editor, write your custom unit data over the original standard units in the game by importing your own version of files such as [icode]Units\UnitData.slk[/icode] and similar files into the map. You can literally open these in Microsoft Excel and add more units in the same manner as the original game developers -- but there are also tools like Widgetizer that you can try. These tools are likely to fail on Reforged, so you might want to ask an AI to make you a new one, but this would be fairly trivial and probably instantaneous for frontier models.
  
• Delete the [icode]war3map.imp[/icode] file from your map, which lists the imported files and would help someone else to reconstruct what was in your map, which you don't want.
  
• Delete the [icode](listfile)[/icode] in your map, which identifies the locations of all files in the map. This will frustrate anybody who tries to open your map in an external tool.
  
• Modify the MPQ header of your map so that it declares itself to be Burning Crusade World of Warcraft format for its MPQ archive storage, instead of Warcraft 3 format. Because the Warcraft 3 game (and by extension Reforged) were made prior to Burning Crusade, they completely skip over the file version. So if the header declares it is a Burning Crusade storage format archive, that doesn't mean anything and the file still launches on Warcraft 3. However, fans who have general purpose tools for opening this kind of compressed storage file make their tools general-purpose because they think that's good programming. And as a result, this will cause them to make a mistake and have their tools crash when opening your file, because their tool thinks it is opening a World of Warcraft Burning Crusade archive instead of a Warcraft 3 format file.
  

We can walk through these suggestions in reverse to get the map back to a state that would open in World Editor.

• So obviously once you know about the Burning Crusade archive version thing, if that's a problem for you, you can just change the version back.
  
• I've already discussed above how you can regenerate the listfile in full, potentially in multiple different ways, and you can do the same thing for the `.imp` file
  
• If your custom units are defined as standard units, obviously in the same way that Widgetizer exists you could simply write a reverse Widgetizer program that dumps them back to a changeset file (.w3u, .w3a, etc) for the map. A convience tool for it does not necessarily exist yet, but that's probably 1 prompt away from having a leading frontier LLM build it for you
  
• Obviously once you have renegerated the listfile and know where all the files are, if the jass script file is located at a stupid path such as "war3.w3mod\_balance\custom_v1.w3mod\scripts\" rather than in the root directory of the map, then you can just put it back.
  
• This is slightly speculative but if your map is missing the war3mapUnits.doo file, but the war3map.j file still exists and declares all of the units, it is very likely that you could ask a leading frontier LLM to look through the war3map.j file, determine the locations of the units, and dump out a war3mapUnits.doo file for you. If that doesn't work, use an open source rewrite of Warcraft 3 client and add a little bit of code that after the map starts up you dump out all the units you see in the game world to a world editor file (this would handle weird edge cases where the script file was butchered beyond basic parsability, since it still has to work in the game by definition)
  
• Don't use the lua programming language
  
• Have one of the leading frontier LLMs change all the variables in your map back to relatively meaningful names based on how they feel about the variables, instead of having them be named "a" and "aa" and "ab"
  
• After the LLM fixes the variable names, have it regenerate the wtg and wct files based on its intuition, which will probably be easy by the time you read this if it's not already
  

Suppose we try this with a map such as DotA, which depending on what version you get is a comical hellscape of file corruption douchebaggery that evolved over a number of years. Even getting the map to parse in my tools usually required throwing the kitchen sink at it. The unit data was regressed multiple times, not only to be stored in the "standard units" format but often with the data placed in unreasonable locations, such as defining units in files originally intended for items. They also played exploit games with the standard unit format parser, reversing the orders of X and Y and such in the SLK declarations and omitting row or column identifiers to the fullest extent possible to reduce the interpretability of the file. Again, if you have the exact code of the Warcraft III game, all of this is trivially defeated by loading the unit data, comparing it to the original game data, saving it back as a changeset file how the World Editor would have defined it, and then putting that in the map.

What this does not cover, however, is the case of data that is "protected" by legitimate cryptography. For example, the Warcraft III game puts a BLIZ logo on maps that are cryptographically signed by Blizzard. As far as I know, this is like Blizzard proving they own a bitcoin -- it is probably mathematically sound, and accordingly you cannot sign a new map that you make to have the BLIZ logo as far as I know, because you cannot cryptographically prove that you are Blizzard. As a result, any time you edit one of these maps in the World Editor, it will lose its official logo. Additionally, you could have a map that is encrypted so that it will only launch on a modified version of the Warcraft III game. If the person distributing the map to you is also distributing computer software to you, then they can give you a version of the game that uses FBX models instead of MDX for example, and then your map would never open on Warcraft III World Editor since that is a program that uses an MDX model loader to display the 3D art. Similarly, at least once in my life I saw a version of the DotA map that was intended to be used with its own custom version of the Warcraft 3 client, and so for all I could tell the map script file simply contained something like "//run" that was not sufficient information for how the map would play. Obviously in this case, the code for how the map operated was probably being provided by the game client itself, due to some Snarklord expecting that everyone he provided the game to would only play the DotA map. In these cases, it's similar to if you just played a different game.

Do not try and protect the map. That's impossible. Instead, only try to realize the truth.
What truth?
That there is no protection.
Then you'll see, that it is not the map that protects, it is only yourself.